OIDC and dynamic ports on the metadata redirect_uris?

[Paul B. Henson]

On 1/23/2026 1:12 PM, Bryan K. Walton via users wrote:

> Does the Shibboleth IdP support this feature?  If so, what should I be
> using for the port wildcard in the metadata?

Reviewing the idp oidc documentation:

https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879133/OPMetadataClientRegistration

It says:

"Each RP is defined with a JSON structure that is defined by the OpenID 
Connect Dynamic Client Registration 1.0 specification. That is, the 
format is just the format of the messages in that protocol."

Looking at the referenced document:

https://openid.net/specs/openid-connect-registration-1_0.html

Under the section "2. Client Metadata", "redirect_uris" is defined as:

"Array of Redirection URI values used by the Client. One of these 
registered Redirection URI values MUST exactly match the redirect_uri 
parameter value used in each Authorization Request, with the matching 
performed as described in Section 6.2.1 of [RFC3986] (Simple String 
Comparison)."

Moving on to RFC 3986:

https://www.rfc-editor.org/rfc/rfc3986.txt

Section "6.2.1.  Simple String Comparison" says:

"If two URIs, when considered as character strings, are identical, then 
it is safe to conclude that they are equivalent."

While I haven't poked into the source code to confirm, it seems doubtful 
that the IDP supports any form of wildcards in static client 
registration data.

 > According to RFC 8252 (section 7.3):
 >
 > "The authorization server MUST allow any port to be specified at the
 >   time of the request for loopback IP redirect URIs, to accommodate
 >   clients that obtain an available ephemeral port from the operating
 >   system at the time of the request."

The enclosing section for 7.3, is "7. Receiving the Authorization 
Response in a Native App".

What exactly is that you're trying to do? A native app is generally 
something running on an end-user's desktop or mobile device, and the 
redirect URL used in this case simply intermediates between a separate 
browser instance used by the user to login and process the 
authentication request and the app which wants the tokens generated from 
said request. The native app calls out to the browser, the browser talks 
to the oauth server, and when complete, the oauth server redirects the 
browser to a URL that allows the browser to deliver the generated token 
to the app.

In these cases, you typically don't have statically registered metadata? 
You would use either unregistered clients:

https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3274833948/OPUnregisteredClientPolicy

Or dynamically registered clients:

https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879077/OPDynamicClientRegistration

Either of those cases would accommodate a dynamic port in the URI, as in 
the former it would not match against anything and in the latter the URI 
registered would have the dynamic port in it...

You say you are trying to implement oauth using dovecot? What client 
application is involved? Where is the client running? On one specific 
system always, or on whatever random client is trying to authenticate to 
dovecot?