Oauth2 Multiple URLs (exclude localhost) about kanidm HOT 6 CLOSED

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.

from kanidm.

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

from kanidm.

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.

from kanidm.

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.

from kanidm.

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)?

from kanidm.

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.

from kanidm.