OpenID Connect, referred to as OIDC, has become the universal standard for single sign-on and identity management on the Internet. It builds an identity layer on top of OAuth2 and is an identity authentication standard protocol based on the OAuth2 protocol.

OAuth2 actually only does authorization, while OpenID Connect adds authentication on top of authorization.

The advantages of OIDC are: simple JSON-based identity token (JWT) and fully compatible with OAuth2 protocol.

Today we will introduce the specific principles of OIDC.

Released in 2014, OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol, which allows clients to authenticate end users based on authentication by an authorization server or identity provider (IdP). identity and obtain user-related information.

OpenID Connect provides a RESTful HTTP API and uses Json as the data transfer format.

We talked about the SAML protocol based on XML format before, and OpenID Connect is used by more and more applications because of its simpler data exchange format and has become a de facto standard.

Let’s take a look at the basic process of OpenID connect:

ID Token is like a user’s ID card. It exists in JWT format and is signed by the OP to ensure that it security.

The way to obtain the ID Token is to send an authentication request to the OP.

Because ID Token exists in JWT format, JWT can be divided into three parts, namely Header, Payload and Signature.

Here we mainly focus on the json content of Payload:

The above are the standard Claims of ID Token.

Now that we know what an ID Token is, how do we request an ID Token in the RP client of OpenID Connect?

Although OpenID Connect does not specify how a user's identity should actually be verified, it is up to the provider to decide. But we usually let the web browser perform the authentication step.

The browser redirects the user to the authentication window of the authentication server. After the user enters the username and password, the user requests the ID token through the OAuth 2.0 protocol.

There are three ways to use OAuth 2.0 to obtain ID Token:

The steps of the Authorization Code process are as follows:

The client prepares an identity authentication request, which contains Required parameters

The client sends a request to the authorization server

The authorization server authenticates the most popular users

The authorization service obtains the unification/authorization of the end user

The authorization server sends the end user back to the client, along with the authorization code

The client uses the authorization code to request a response from the Token endpoint

The client receives to the response, the response body contains ID Token and Access Token

The client verifies the ID Token and obtains some identity information of the user

The picture above is an implicit authorization For example, unlike the Authorization Code mode, the authentication server returns an access token fragment. Only with this fragment, we cannot obtain the access token.

Here we need to make an additional request to the client resource server, and the server will return a script. Through this script, we parse the access token fragment and obtain the final access token.

The mixed mode is less commonly used. It is a mixture of the previous two modes. It allows the token value to be obtained from the front end and the back end respectively.

So what can we do with the requested ID Token?

The server does not need to store session information, we only need to verify the token on the server.

Here we give an example of obtaining an ID token using authentication code authorization.

The following is an example of redirection:

On the OP side, it will be checked whether a valid user session already exists, otherwise the user login interface will pop up to allow the user to log in.

After successful login, the client will be redirected to the redirect_uri with the authentication code:

The code returned above is just an intermediate product, and the RP needs to submit the code to the OP in exchange for the ID. token.

This time we directly use a backend POST request:

If successful, the OP will return a JSON object with an ID token, access token or refresh token:

The format of the ID token is JWT.

The ID token we obtained already contains some very useful claims information.

In fact, ID Token can also contain other user info information:

Such as name, profile, picture, email, gender, birthdate, phone_number, address and other useful information.

We can add additional scopes when requesting the token:

For example, in the above example, we add additional email information, then the OP will add email to the token options.

For example: