Oauth2 Multiple URLs (exclude localhost)

[Firstyear]

We have had a number of past issues asking for multiple url support in oauth2. So far almost all of these requests have been about allowing an RP to have a https://example.com name while also allowing redirects to http://localhost.

However, there may be a case where someone wants to allow multiple names such as https://au.example.com and https://nz.example.com.

We need to understand why someone may want multiple URLs like this. From our app portal page, we can only nominate a single outbound link, which may constrain possible deployment options when multiple urls are involved.

This issue is intended to serve as a discussion about multiple public urls only. We need to know how or why someone may deploy these so that we can properly implement a design to facilitate this.

[0xC0ncord]

One use case for this is to have multiple environments where the application is deployed but only one single OAuth2 client, e.g. a production, staging, and dev environment:

• myapp.example.com
• myapp-staging.example.com
• myapp-dev.example.com

[Firstyear]

One use case for this is to have multiple environments where the application is deployed but only one single OAuth2 client, e.g. a production, staging, and dev environment:

* myapp.example.com

* myapp-staging.example.com

* myapp-dev.example.com

This use-case is exactly why I don't want to allow multiple origins. You should never mix production staging and dev credentials and application domains. This would allow a dev access token to be usable against a production resource server. So compromise of dev becomes compromise of production.

At the moment by forcing single origin, we force you to have separate security domains between each client, preventing users from making the security mistake in the first place.

[someone-stole-my-name]

Agree on never mixing credentials between stages. However, this is still a valid use-case if you have N distinct but equal environments, e.g. multiple and completely isolated staging environments:

• myapp-dev-1.example.com
• myapp-dev-2.example.com

Our use case is on-demand staging environments, where all of them are equal for the purposes of kanidm but under different domains.

[0xC0ncord]

This use-case is exactly why I don't want to allow multiple origins. You should never mix production staging and dev credentials and application domains. This would allow a dev access token to be usable against a production resource server. So compromise of dev becomes compromise of production.

At the moment by forcing single origin, we force you to have separate security domains between each client, preventing users from making the security mistake in the first place.

I agree I think that's a very compelling reason to not have such a capability. Truthfully I can't think of another use case myself -- I don't personally have a need for this feature. I was searching around for potential use cases based on the fact that Keycloak supports this but the reasoning I provided was the only one I could find.

[Firstyear]

Yeah. The previous usecase that almost all requests were related too was to have public clients with localhost redirects - we've solved that now in a more secure, and simpler manner.

[TheRealGramdalf]

I'm really not sure how this is intended to work, but would multiple URLs/URIs be required for e.g. astubenbord/paperless-mobile#374 (using a paperless:// URI with a mobile application)? Or does that only concern the callback URI, since actual authentication happens directly in a web page (which uses the correct URL)?

[yaleman]

I'm really not sure how this is intended to work, but would multiple URLs/URIs be required for e.g. astubenbord/paperless-mobile#374 (using a paperless:// URI with a mobile application)? Or does that only concern the callback URI, since actual authentication happens directly in a web page (which uses the correct URL)?

That could be a valid use case, but we'd need to see how it worked in general (ie, can it be tested with an RS dedicated to that URL?)

.. though most likely the auth will be against the server's URL, which the app can request a token for using that URL.

[pando85]

For example I'm setting up Immich and it requires three URIs:

• app.immich:/ - for logging in with OAuth from the Mobile App
• http://DOMAIN:PORT/auth/login - for logging in with OAuth from the Web Client
• http://DOMAIN:PORT/user-settings - for manually linking OAuth in the Web Client

Source: https://immich.app/docs/administration/oauth#prerequisites

[Firstyear]

Currently do we actually support non-http urls anyway?

I think we could even end up supporting this via the future "multi-client" oauth2 feature I have in mind.

[pando85]

That's not even critical because you can change the URL endpoint for the mobile app and it can be http.

Could I implement the multiple redirect URLs? Do you have something in mind for this feature which is supported in different IDMs with Oauth2/OIDC support?

Also, I found other applications that need this like ArgoCD CLI which is a crucially app for any organization based on GitOps.

[Firstyear]

Currently we've been working to improve how we handle keys server side, which will allow us to associate multiple clients to a "oauth2 client domain" where they all share the same keys. This way, we can have two clients (one for each url) where the tokens are valid for both clients and resource servers. That way we retain the current and same logic, and you get a clearer distinction between which url is associate to which client, and we retain our strict logic about redirect flows

[pando85]

Ok, that will work.

Is that currently implemented in the last dev version?
Just to be clear, using just one client ID (in the application) we could use any endpoint associated to the shared clients, no?

It looks like a good solution for me.

[Firstyear]

Not yet, it's on the todo list :)