Before jumping at this post please refer to the previous post https://www.jstack.io/post/oauth2-0-flows-overview in order to get a better understanding of the OAUTH2.0 flows.
Overview:
OpenID Connect (OIDC) is an authentication protocol, based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications.
While OAuth 2.0 is about resource access and sharing, OIDC is all about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where you login, and then taken back to the website.
For example, if you chose to sign in to your website using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize your website to access your information, Google will send back to your website information about the user and the authentication performed. This information is returned in a JWT. You'll receive an Access Token and, if requested, an ID Token.
OIDC specification also specifies a list of standard claims:
How it works:
Let's use the example we mentioned earlier, signing into your website using your Google account, for a high level overview on how the flow works:
1. When you choose to sign in to your website using your Google account, your website sends an Authorization Request to Google.
2. Google authenticates your credentials or asks you to login if you are not already signed in, and asks for your authorization (lists all the permissions that your website wants, for example read your email address, and asks you if you are ok with that).
3.Once you authenticate and authorize the sign in, Google sends an Access Token, and (if requested) an ID Token, back to your website.
4.Your website can retrieve user information from the ID Token or use the Access Token to invoke a Google API.
Remember:
Access Tokens must never be used for authentication. Access Tokens cannot tell us if the user has authenticated. The only user information the Access Token possesses is the user ID, located in the sub claim.
ID Tokens should not be used to gain access to an API. Each token contains information for the intended audience (which is usually the recipient). Per the OpenID Connect specification, the audience of the ID Token (indicated by the aud claim) must be the client ID of the application making the authentication request. If this is not the case, you should not trust the token. Conversely, an API expects a token with the aud value to equal the API's unique identifier. Therefore, unless you maintain control over both the application and the API, sending an ID Token to an API will generally not work. Since the ID Token is not signed by the API, the API would have no way of knowing if the application had modified the token (e.g., adding more scopes) if it were to accept the ID Token.
Client Applications should treat Access Tokens as opaque strings, since they are meant for APIs. Your application should not attempt to decode,validate them or expect to receive tokens in a particular format. The resource server is responsible for validating access tokens. The client application is responsible for decoding and validating the open id tokens.
Access Tokens (which aren't always a JWT) are meant for use by an API.
The Access Token's purpose is to inform the API that the bearer of the token has been authorized to:
1. Access the API
2.Perform a predetermined set of actions (these actions are specified by the scopes granted)
In the next session we will see more in details from a practical perspective how one specific identity provider has implemented these flows. In this case is going to be Microsoft AAD.
Comments