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

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 code and token. Both types. OIDC extends this attribute by adding id_token and none. Then the value of response_type may now have the following combinations.

  1. code
  2. token
  3. id_token
  4. code token
  5. id_token token
  6. code id_token
  7. code id_token token
  8. none

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:

  1. EU : End User EU : End User
  2. 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
  3. OP : OpenID Provider, the service provider that authenticates the EU
  4. ID Token: JWT format, EU’s authentication through the generation of credentials for RP consumption
  5. 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.

  1. the RP sends an authentication request to the OP.
  2. the OP first authenticates the EU and provides authorization after confirming that there is no error.
  3. the OP returns the ID Token and Access Token (if required) to the RP.
  4. the RP sends a request UserInfo EndPoint using the Access Token; (optional)
  5. the UserInfo EndPoint returns the EU’s Claims.(optional based on step 4)

OIDC

In addition, OIDC summarizes three flows for reusing OAuth 2.0.

  1. Authorization Code Flow: Use OAuth2’s Authorization Code pattern to exchange for Id Token and Access Token.
  2. Implicit Flow: Use OAuth2’s Implicit mode to get Id Token and Access Token.
  3. Hybrid Flow: A hybrid implementation of the above two.

Summary

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.

Reference https://felord.cn/about-oidc.html