In the previous article we reviewed the OAuth 2.0 process with an example, and pointed out the limitations of OAuth 2.0: The client cannot identify the resource owner as the correct advocate, and while commercially available OAuth 2.0 can guarantee authorization security, OAuth 2.0 itself does not provide clear specifications for user authentication. This is where OIDC comes into play.
OIDC is a variant of OAuth 2.0.
OIDC (OpenID Connect) builds on the Auth 2.0 process and introduces the concept of ID Token, an end-user authentication identifier. The OIDC process must be compliant with OAuth 2.0. OAuth 2.0 is a specification on how to issue AccessToken; while OIDC is a specification on how to issue ID tokens. Although both tokens are embodied in the form of JWT.
An OAuth2.0 authorization endpoint defined in RFC 6749 is used to request authorization, and requires a
response_type parameter to inform the authorization server of the type of authorization required, which typically includes both
token. Both types. OIDC extends this attribute by adding
none. Then the value of
response_type may now have the following combinations.
code id_token token
In addition if the request is an OIDC authorization authentication request it must also contain a
scope parameter with the value
openid, which is the key to distinguishing between normal OAuth 2.0 and OIDC.
Key terms for OIDC
OIDC specifies some terms to raise our learning threshold:
EU: End User
EU: End User
RP: Relying Party i.e. client, the final consumer of authorization and authentication, I can’t figure out why we need to play with redundant concepts
OP: OpenID Provider, the service provider that authenticates the EU
ID Token: JWT format, EU’s authentication through the generation of credentials for RP consumption
UserInfo Endpoint: interface to query basic user information through credentials, recommended on HTTPS.
The OIDC process
OIDC replicates the authorization process of OAuth2.0, adding some “small actions” to the authorization process for user authentication. In combination with its terminology, the general flow is as follows.
- the RP sends an authentication request to the OP.
- the OP first authenticates the EU and provides authorization after confirming that there is no error.
- the OP returns the ID Token and Access Token (if required) to the RP.
- the RP sends a request UserInfo EndPoint using the Access Token; (optional)
- the UserInfo EndPoint returns the EU’s Claims.(optional based on step 4)
In addition, OIDC summarizes three flows for reusing OAuth 2.0.
- Authorization Code Flow: Use OAuth2’s
Authorization Codepattern to exchange for Id Token and Access Token.
- Implicit Flow: Use OAuth2’s
Implicitmode to get Id Token and Access Token.
- Hybrid Flow: A hybrid implementation of the above two.
Protocol this thing is really dry and difficult to learn, you need to combine some scenarios to make it clear, to be honest, some things I also foggy, but this is something that can not be skipped. Don’t think too much about why, then we will combine some scenarios to figure out the above terms and processes.