Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenID #268

Open
morgverd opened this issue Feb 6, 2023 · 0 comments
Open

OpenID #268

morgverd opened this issue Feb 6, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@morgverd
Copy link

morgverd commented Feb 6, 2023

OpenID is another spec optional for OAuth 2.0.

Why should McAuth use/support OpenID?

OAuth and OpenID were created to tackle two similar yet different scenarios. OAuth was created to allow for user authorization, for example the OAuth may allow for the bearer token to access scoped parts of the users account (such as requesting "profile.edit" scope). In this case, you are authorizing an external service to do x on your account.

OpenID instead focuses on user authentication. Instead of asking for permission to interact with a user account, it is simply asking the target application about the users identity (uuid, username in this case).

OpenID Features:

OpenID offers a very large feature set (such as session management etc for federated networks), not all of which I'm suggesting be implemented here. Instead, I am suggesting two main things:

OpenID Configuration Discovery:

OpenID defines an autodiscovery format allowing for applications using OpenID to autoload all required configuration/routes automatically. (This is used by alot of enterprise connections mainly, however it is also becoming more popular as a quick config option).

The route must be /.well-known/openid-configuration and it must return JSON (even in error state).

OpenID User ID:

This is by no means required, however it can be quite useful for single page applications implementing OpenID flow. It essentially returns a hashed id_token that contains the users basic identity (username, uuid in this case, since email can't be gathered) in the token request.

This means that instead of requiring two requests (one to oauth/token to get access token, then to api/profile with token) the info is returned in the first request (oauth/token).

This does however require JWK (JSON Web Keys) certificates to essentially sign each id_token (verifying identity provider authenticity), hence why its not required (since it could be a pain to implement).

@SpraxDev SpraxDev added the enhancement New feature or request label Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants