# Understand the OIDC process
# Understand the OIDC process
This article describes several authentication modes of OIDC authentication protocol for readers, including authorization code mode, implicit mode, and mixed mode; as well as the triggering and processing methods of OIDC authorization in business. With flow chart to assist understanding.
# When is certification required?
When your users need to access protected resources on the server, such as user order data, user shopping carts, they need to carry id_token.
id_token is the identity of the user, just like an ID card. id_token is a JWT Token (opens new window), which consists of three parts, aaa.bbb.ccc. Where aaa is meta information, bbb is user information, and ccc is signature. aaa and bbb are all JSON objects after base64 (opens new window) encoded characters. ccc is the base64-encoded value of the signed binary sequence.
Three parts of JWT Token
Meta information: There are some attributes used to describe the signature algorithm of this id_token JWT, the type of the payload, etc.
Payload: There will be some attributes in it, which are used to describe the identity of the authenticated person and the information of the token, such as user id, issuing time, recipient, etc.
Signature: The aaa and bbb parts are connected by ., plus a private key for digest calculation. If the token has been tampered with, such as changing the authentication subject. Then the signature calculated by the server locally and the signature carried in the ccc part of the token will be inconsistent, thus rejecting the request.
.png)
Data protection middleware
You should implement a data protection middleware on the server to enable specific data interfaces. If the request does not carry id_token or the signature verification fails, the user will be redirected to the login page. If the id_token verification is successful, return Data to the user.
# When is authorization required?
You provide identity services to others, and other applications need to obtain user information from your server. For example, Github provides identity services, and other applications can ask for user information from Github and complete user registration on their platform, that is, three-way login.
The essence of third-party login is to allow the user to allow other applications to access his information on your server, and then you will generate an Access Token to the third party. As long as the third party owns this token, he can access this person on your behalf on your behalf. Data on the server.
# OIDC process
Since authentication and authorization are required, how do your server, third-party server, and user communicate? How to issue tokens? What kind of norms should be followed? OIDC is a set of authentication and authorization specifications. It is widely used, lightweight and simple. Based on OAuth 2.0, it can be used for both authorization and identity authentication.
access_token is used for authorization, and id_token is used for authentication.
# Authorization code mode
The authorization code mode is the most commonly used OIDC process.
- The third-party application initiates an authorization request (I need to access the user's data on your server!)
- Your server asks whether the user agrees to the authorization, asks the user to enter the user name and password, and pops up the information item requested by the other party (OK, I first ask whether the user agrees to you to obtain this information)
- Return an authorization code to the front-end (or back-end) of the third-party application. (Give this authorization code to your backend, and let him get the token with it!)
- The three-party application backend carries this authorization code to request data from the token issuance interface of your server. (Please give me a token, the authorization code is xxx)
- Return id_token access_token. (Ok, this is your token, you can bring access_token to the user information interface to get data)
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | Issuing | X | X |
| Token | X | Issue | Issue |
Scope without openid
It can be seen that no ID Token is returned at the end.
# Implicit mode
When initiating an authorization request, the query parameter response_type=token uses implicit mode. Even if openid is included in the scope, the ID Token will not be returned. The implicit mode can get the Access Token immediately after one request.
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | X | Issuing | X |
When an authorization request is initiated, the query parameter response_type=id_token uses the implicit mode. Only ID Token is returned.
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | X | X | Issuing |
When initiating an authorization request, the query parameter response_type=id_token token uses implicit mode. Both ID Token and Access Token are returned.
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | X | Issue | Issue |
It can be seen that the implicit mode is the simplest and most direct, but it is not as secure as the authorization code mode because it may expose the Access Token on the front end. The implicit mode requires that the callback address must be https.
# Mixed mode
The hybrid mode means that after an authorization request is initiated, both the authorization code and the Access Token or ID Token are returned.
When initiating an authorization request, query parameter response_type=code id_token is used in mixed mode.
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | Issue | X | Issue |
| Token | X | Issued | Issued |
When initiating an authorization request, the query parameter response_type=code token is used in mixed mode. If there is openid in the scope, the information returned is as follows:
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | Issuing | Issuing | X |
| Token | X | Issue | Issue |
If the scope does not contain openid, the information returned is as follows:
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | Issuing | Issuing | X |
| Token | X | Issue | Issue |
When initiating an authorization request, the query parameter response_type=code id_token token is used in mixed mode. The return status of various types of information is as follows:
| Interface | Authorization Code | Access Token | ID Token |
|---|---|---|---|
| Authorization | Issuing | Issuing | Issuing |
| Token | X | Issue | Issue |
This usage can get all content at once.
Reference