Allow Wildcard port in Redirect URI as per RFC 8252

[MGough]

Feature:
http://localhost:* should be a valid redirect URI which can be used for native applications such that my application can pick any free port when authentication is being performed on a user’s machine.

Description:
According to RFC 8252 “OAuth 2.0 for Native Apps” RFC 8252: OAuth 2.0 for Native Apps
“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.”

However Auth0 currently rejects Redirect URIs which contain a wildcard port (e.g. http://localhost:*). Native applications have no guarantee about the port they’re run on due to other processes on the user’s machine. Many other services and libraries are written to meet the spec in this RFC (as it’s best practice) but due to Auth0 not supporting it they are incompatible with Auth0.

This documentation from oauth.com (sponsored by Okta!) agrees with this RFC: Redirect URLs for Native Apps - OAuth 2.0 Simplified
“”“In order to suppor this use case, the authorization server will have to support registering redirect URLs beginning with http://127.0.0.1:[port]/ > and http://::1:[port]/, and http://localhost:[port]/. The authorization server should allow an arbitrary path component as well as arbitrary port numbers. Note that in this case it is acceptable to use the HTTP scheme rather than HTTPS, as the request never leaves the device.”“”

Use-case:
I’m building native applications using frameworks such as Tauri, Electron, or even just CLIs on devices where input is not constrained. The user has a copy of the product on their machine, and authentication needs to be redirected to a localhost port. I have no control over the free ports on these machines, and in some cases can’t guarantee that the OS has released a port from a previous version of our application, such as during an upgrade process.

I’m also certainly not the first to ask about this, although it looks like I may be the first to request it here. With prrevious questions on the topic just being closed with “We don’t support this” without any accompanying explanation as to why, or that it will be implemented in future.

See:

Is there a way to select a callback URL port in the request?

We are implementing OAuth for a Windows desktop app using a loopback HTTP listener to receive the tokens. This thread asks about using a wildcard port in the callback URL, and it was mentioned that this isn’t currently supported. Has it been implemented since then, or if not, are there plans to implement it?

Random local ports on redirect_uri

Is it possible to configure a “MACHINE TO MACHINE” application to use a random port in the redirect_uri parameter? The use case is the following, I have a CLI app that allows you to do OAuth/OIDC but it wants to listen in a random port (127.0.0.1:0) so it can work on most environments. This use case works on other identity providers like Google or Microsoft, but it does not work on Auth0. I get a “Callback URL mismatch” error unless I specify the right port in “Allowed Callback URLs”

Are port wildcards supported? (PKCE for Desktop apps)

Welcome to the Auth0 Community @ab11! We do support wildcards in callback URLS. See: Auth0 Configuration (Web Apps + SSO) Please let me know if you have any more questions!

[konrad.sopala]

Hey there!

Thanks for creating this feedback card! Make sure to upvote it so that it attract as much attention from other community members as well!

[hammer.mario]

Hello,

I have the same issue. I’ve been thinking about the following:

1. The CLI app open an arbitrary port, and then encodes the port in the state that is sent with with the authorisation request to the /authorize endpoint
2. The redirect URL is an endpoint in your backend, which then reads the localhost port from the state, and then you redirect yourself.

Could this work?

[codefi]

I think it would be useful to support wildcards for localhost ports too.
We have several apps running on different ports and sometimes those ports are random.