You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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).
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).
The text was updated successfully, but these errors were encountered:
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 toapi/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).The text was updated successfully, but these errors were encountered: