The last article realized the integration of identityserver4 and asp.net core identity. Users added through the identity registration function can obtain access tokens in the form of password. However, both client credentials and password processes are oauth2.0 processes. This article will first introduce the basic concept and usage of openidconnect.
This article includes the following contents:
Introduction and basic concepts of openidconnect
In addition, it can be seen from the following answers that oauth2.0 is an authentication / authorization framework, and openid connect provides identity function based on these. Identity is the question of “who”.
For details on how to implement oidc, please refer to the document:https://openid.net/specs/openid-connect-core-1_0.html, the following keywords can be found in the document: ID token, authentication, authentication request, authorization code flow, implicit flow, hybrid flow and response_ Type、Authorization Endpoint、Token Endpoint。
And two tables, oidc authentication process table:
The corresponding type (response) corresponding to the oidc authentication request_ Type table:
There is also a flow chart:
The following information can be obtained from the above Keywords:
- ID Token: is a JWT containing a specific claim. A specific claim refers to the information generated by the authentication server when authenticating the end user for use by the client, such as issuer, end user ID (sub), client ID (AUD), expiration time (EXP), token publishing time (IAT), and user authentication time (auth)_ Time), and other declarations may also be included. The ID token is issued by the authentication server (identity server4, OP) and submitted to the client (RP) for authentication.
- Authentication: the authentication (login) provided by identityserver4 (OP). After the end user passes the authentication (login) of identityserver4 (OP), he can initiate an authentication request, or if the user does not authenticate when initiating an authentication request, he will be redirected to the authentication interface for authentication.
- Authentication Request: a request initiated to the authorization endpoint of identityserver4 (OP) to obtain ID token, authorization code, or even access token.
- Authorization Code Flow、Implicit Flow、Hybrid Flow: three different request processes for authentication request.
- Response_Type: one of the parameters of authentication request. It determines which request process to use according to the setting of this parameter.
- Authorization Endpoint: authorization endpoint for receiving authentication requests.
- Token Endpoint: token endpoint used to receive access token acquisition requests.
From the two tables, we can know the characteristics of the three authentication processes, such as which endpoint each token returns from, whether to disclose the token to the user agent (such as the browser), whether to support refreshing the token, etc. Three authentication processes pass the specified response_ Type. For example, the parameter value isProcess of authorization code when code，Id_ Token and ID_ Implicit process when token, includingCode and token are mixed processes。
The flow chart can understand the whole authentication and authorization steps of openidconnect, and the final specific implementation directly corresponds to the authorization code process, implicit process and hybrid process.
Oidc authorization code flow and Implementation
The following is a detailed explanation of the authorization code process. First, the steps of the authorization code process are as follows:
The authorization code process consists of eight steps. In short, the client sends an authentication request to the authentication server (the response type is code). After the authentication server authenticates the user and allows and authorizes the user, it sends the authorization code to the client. The client obtains the ID and access token from the token phase of the authentication server through the authorization code, Then verify the ID token and obtain the user’s ID information.
Next, use the previously created identity server to implement authentication and authorization based on the authorization code process.
In the previous article, the support for users and asp.net core identity components has been added to the identity server. At present, there is no need to make any modification. In other words, the current identity server can issue ID tokens. Only the support of the client is required to complete the authorization code process. We use the web API added in the previous article to demonstrate, Comment out the original authentication code based on JWT bearer, and add the authentication service based on cookie and oidc (Note: when adding oidc, the client information needs to be consistent with the database in identityserver, and the redirection address configured by the corresponding client needs to match the application):
Ensure that the redirection address of the “interactive” client is “application address / sign oidc”. Note that the redirection address is actuallyClient (webapi)The authentication processor added through the method. Addopenidconnect to handle odic authentication:
You will jump to the login page of the authentication server:
Note: the default login address of identityserver4 is / Account / login, but the login page generated by asp.net core identity is / identity / Account / login. In order to ensure correct jump, the following configuration needs to be added:
The following is the URL information of the login page:
You can see three parameters:
1. The first parameter is that the client sends an authentication request to the identity server, but since the end user has not logged in yet, the login page will be skipped first, and / connect / authorize / callback will be returned after logging in.
2. The third parameter is the response type. The value is code, which represents the currentUse authorization code process。
3. The second parameter, redirection URI, is the address that will carry the authorization code redirection after authorization, that is, the oidc authentication address of the web API program.
For the eight steps of the authorization code process, it has completed the first three and is currently in the end user authentication (incomplete – user name and password have not been entered):
After entering the user name and password to log in, you can see the protected content:
Here, the last four steps of the authorization code process are completed:
The whole process is mainly the interaction and completion between the application (client) and the authentication server. The relevant authorization code, ID token and access token are “not” sent to the browser, so the authorization code process is also the most secure process.
How to obtain the corresponding access token on the client? Through httpcontext. Gettokenasync (“token name”); You can obtain the corresponding token:
The reason why tokens can be obtained through httpcontext is that when adding the oidc authentication service, the savetokens option is set to true. When the authentication is successful, the program will automatically store all kinds of tokens in the authenticationproperties, and finally encrypt and write them into the cookie. Therefore, although the data is saved in the browser, due to encryption, That’s why it was said that they were “not” sent to the browser:
So how to implement the last step of the authorization code process? There are two methods. One is to access the userinfo endpoint of the authentication server directly in the program after obtaining the access token. The other is to set getclaimsfromuserinfoendpoint of the oidc option to true:
User claims information for userinfo not obtained:
After obtaining the user claims information of userinfo, you can see that there is an additional claim with name (why there is only one claim will be explained in subsequent articles):
Implicit process and implementation of oidc
Now that the most complex authorization code process has been implemented, there must be no problem with the simple implicit process. Here is a demonstration of how to obtain the token directly into the browser through the implicit process.
First, create a client that supports implicit processes:
Note: create a client in the database and copy the existing data. The client password is encrypted and stored. After copying, use the copied client password. In addition, because the token information needs to be sent to the browser, it is necessary to set “allowaccesstokenviabrowser” in the client information to 1.
Configure the client information to the client application:
The implicit process requires the response type to be ID_ Token or ID_ Token and token.
After configuration, run the program with the following parameters to directly access the authorization endpoint of identity server:
After successful login, the program will automatically jump to the parameter redirect_ Uri specifies the path and carries the token and related information:
After formatting the entire URL, the following results are obtained:
This article introduces the basic concept of openidconnect, and demonstrates the authorization code based and implicit process through the existing identitysever program. The authorization code mode is a relatively secure mode. All key data, including authorization codes and various tokens, are completed in the background of the client, If necessary, the relevant tokens can be encrypted and put on the client in the form of cookies for subsequent use. The implicit mode can return all kinds of tokens to the browser. This mode can be used in single page applications. Tokens are managed by JS and used to access protected resources.
In addition, what we can see so far is that the role of identityserver or identityserver4 is to verify the client information, the user name and password information of the end user, and then generate authorization codes and various tokens, and the authentication and use of tokens are actually carried out in the client.
Finally, oidc is an authentication protocol, so how does authentication and authorization reflect in asp.net core applications? Let’s talk about this in the next article.