In the previous article, we covered authentication in Asp.net Core and described the process of authentication and authorization as follows:

　　

Note: The change flowchart has been modified. After logging in to third-party users, they do not obtain code/ ID_token /access_token. After logging in, they access protected resources in identityServer (Endpoint). It is different from the Oauth2.0 Password GrantType method that obtains the token directly through the user name and Password to realize the authorization code flow, implicit flow and mixed flow through the initiation of authentication request.

In asp.net core applications, the authentication code process can use the user name and password of the third party IdentityServer, obtain through a series of tokens and userinfo, and finally generate the identity information carrier (Cookie). Asp.net Core applications use cookies for authentication. This process is no different for the user from a normal asp.net core application (especially an application based on asp.net core identity). The user logs in with a username and password and then enters the system. For the application, authentication is still done based on cookies, but the data needed to generate cookies is provided by a third party.

However, due to the particularity of single-page application, its UI rendering and business logic processing are completed by the browser, while the server does not have relevant functions (only static file transfer is required). Secondly, single-page application will have cross-domain problems, so cookie is not suitable as the identity information carrier of single-page application. This article shows you how to use JWT for one-page application authentication.

The main contents are:

  • Create a simple one-page application project
  • Access protected resources using a one-page application
  • Oidc Client profile
  • Various uses of ODC-client.js
    • Pop-up login/logout
    • Silent login and silent refresh
    • Session to monitor
  • summary

Create a simple one-page application project

Note: the single-page applications completely refer to official document, introduces the key points of this section is only for, see document: identityserver4. Readthedocs. IO/en/latest/q…

Create a new asp.net core web application:

2, add OIDC JS component:

Oidc JS client library: github.com/IdentityMod…

NPM can be installed via NPM or downloaded directly from Github. Here is how to install NPM:

npm i oidc-client

　　

After the installation is complete, you can find the related files of ODC-client in the related directory:

　　 

Copy it to the appropriate location.

3, through the database to add a Client information (if it is based on memory, so you need to add a Client instance, as shown in the document: identityserver4. Readthedocs. IO/en/latest/q… , authorization configuration for single-page applications:

Note the following key information when adding clients:

  • Authorization Type The authorization code type is supported.
  • No client password required;
  • Allows clients to access IdentityServer across domains.

Refer to the following memory example:

　　

Database data:

　　

4. Add the login, API access and logout business logic code app.js based on ODC-client:

The UserManager object is initialized:

　　

Login jump using UserManager instance:

　　

Use the UserManager instance to get the user information and then access the protected resource using the Access token in the user information:

　　

Use the UserManager instance to log out:

 　　

5. Add function page index.html, including login, API access and logout functions:

　　

Add redirection page for processing authorization code:

　　

Now that the one-page application has been created, we’ll use it to show how it authenticates and accesses protected resources.

Access protected resources using a one-page application

We use a simple asp.net core web API project (used in this series of articles) to demonstrate that the key to a normal API project is:

1. Add authentication handlers based on JwtBearer:

　　

2, Add cross-domain processing, add cross-domain policy configuration:

　　

3. Apply cross-domain configuration to asp.net core application request pipeline:

　　

4. The protected content is marked by the authorize characteristics:

　　

When everything is ready, run the three applications. The single-page application runs and opens the index.html page, which looks like this. There are three functions: login, API call, and logout:

　　

Login: it actually calls the signinRedirect method of the OIDC Client. Semantically, it uses the redirect method to log in. The actual effect is as follows:

Jump to the IdentityServer login page, and let’s see what it does essentially, okay?

It is actually initiated an authorization code process of authentication request (request process may refer to: www.cnblogs.com/selimsong/p… , the current user is not logged in to or authenticated by IdentityServer, so the user is redirected to the login page.

When we pass the user name password after login, IdentityServer will continue to complete the authorization code processes, subsequent processes is to generate the corresponding authorization code and return to the client configuration redirect uri (in this case, https://localhost:5003/html/callback.html),

In order to see the entire request, this example adds a debugging breakpoint to the callback.html page:

　　

The breakpoint is after the signinRedirectCallback method, after the callback processing is complete (at this point the token and other information has been retrieved), and before the index.html page is jumped.

The following is the request information when the breakpoint is hit after the user name and password are submitted:

As can be seen from the figure above, after the user name and password are entered and submitted (the first request), the authorization code process (the second request) is completed, and the authorization code is redirected to the redirection address configured by the Client (the third request).

The third request comes to our callback. HTML page. The loading of the page first requests the ODC-client. js file, and then completes the subsequent request by the instantiation of UserManager and signinRedirectCallback method. Subsequent requests include openID configuration information request, Token request, user information request (userinfo) request, and check session request.

As a result of the above series of requests, we can find relevant data information in the browser’s session store:

　　

After the breakpoint has passed, we go to the index.html page and print out the login user information:

　　

After clicking the Call API button, the program will obtain the Access_token from the stored information, and carry the access_token to complete the request:

Clicking the logout button will remove user information and redirect to the IdentityServer logout page:

Note: You need to configure the logout URL for IdentityServer4:

　　

A brief introduction oidc – client. Js

The previous content is based on IDC client. Js, that is JavaScript version of THE OIDC client class library to achieve a single page application, so IDC -client. Js in the end for us to provide what function?

Idc-client. js is a JavaScript class library that supports OIDC and Oauth2.0 protocols. In addition, it also provides user session and Token management functions. The core type in the class library is UserManager, which provides high-level APIS for user login, logout, user information management and so on. In the above example, UserManager is used to complete login, Access Token acquisition and logout.

Idc-client. js or UserManager should pay attention to the following aspects:

  • Configuration: The purpose of the configuration is similar to the oid-based authentication configuration of asp.net core. It is used to specify the address of identityServer, Client information used for authorization, authorization flow (authorization code or implicit flow), redirect address after authorization, and Scope information of the request. For more configuration parameters, see github.com/IdentityMod… , as shown in the figure below:

　　

Note that since the code above is visible to the user, the Client password is omitted.

  • Methods: Provides user management, login, logout, and related callback methods, in addition to session status query and open/close silent refresh (token) methods. There are three types of login/logout: jump, silent, and eject. How to use them will be explained later.

　

  • Properties: Can return the configuration, event, and metadata services of UserManager.
  • Events: UserManager contains 8 events, such as user login/logout, access token expiration, etc. :

　　

The above reference documents: github.com/IdentityMod…

Various uses of ODC-client.js

Pop-up login/logout

Popup login/logout is literally a popup that opens the Login/logout page of IdentityServer.

Here is a pop-up login (just call the signinPopup method of UserManager) :

　　

Note: The callback page requires signinPopupCallback:

　　

The following figure shows the pop-up logout:

　　

Silent login and silent refresh

Silent login and silent refresh refer to the signinSilent and startSilentRenew methods. Note that the principle of startSilentRenew is actually concerned with the accessTokenExpiring event, When the token is about to expire, call signinSilent for silent login.

There are two silent login modes: one is based on session, and the other is based on refresh token, which has a higher priority. In other words, when the refresh token exists, it uses refresh token to log in by default. Refresh token is easier to understand, but what is session? It is actually the state maintained after logging in to IdentityServer. As mentioned in the flow chart at the beginning of this article, we can authorize through the authorization code process because we have access to the protected authorization endpoint of IdentityServer after logging in, so that we can obtain the authorization code and related tokens. The idea here is that the browser saves the login status, so you can access the authorization endpoint again to retrieve and refresh the Token information.

For silent login based on session, the following figure shows the request information initiated after clicking the silent login button, that is, the normal process of obtaining token and user information after receiving the authorization code:

The signinSilentCallback method is used to call back the page, and no longer needs to jump to the page:

　　

In silent login based on refreshing token, the client must obtain the refreshing token before refreshing token login. In OIDC, the client must support scope offline_access and carry this scope when initiating token acquisition:

　　

After the configuration is complete, log in to the storage again to obtain the token. Refresh the token information:

　　

Then perform silent login again (the corresponding client needs to support the authorization mode of refresh_token) :

　　

Silent login request information:

　　

The response message contains the new token:

Session to monitor

Session listening is enabled by default and is logged out of IdentityServer through a new browser window during normal login (the purpose is to clear the session information stored in the browser by IdentityServer) :

　　

The Token and user information can be cleared on receipt of the error message. The single page application can be logged out when the IdentityServer session ends:

summary

This article introduces the identity authentication process of single-page applications using IdentityServer and the application of IDC-client. js JavaScript library. Idc-client. js ADAPTS TO OIDC protocol and provides rich functions and mechanisms. Using this library can greatly reduce the amount of development in the real world.

When it comes to the authentication of single-page applications, the most fundamental mechanism is nothing more than obtaining Access Token and Refresh Token. Access Token is used as the carrier of identity information to complete authentication, and Refresh Token is used as the key to update Access Token. Ensure that the Access Token does not expire to ensure that users can Access related resources.

However, if the Oauth2.0 protocol is used to realize the login of single-page application (Password authorization mode), there will be some problems. First, the single-page application is not trusted for the authorization server, but the Password authorization is initiated by the single-page application, and the user information and Password belonging to the authorization server will pass through the untrusted single-page application. This will cause some security problems, secondly, after using Oauth2.0 protocol to complete the authorization, there is no association between the application and the authorization server, the authorization server does not retain user sessions, and can not realize the function of user logout linkage (that is, one party can notify the other party when logged out), This is what the IdentityServer4 or OIDC protocol deals with.

In the next article, we’ll continue with session management for IdentityServer4 or OIDC and delve into their logins and logouts.

 

Reference:

Identityserver4. Readthedocs. IO/en/latest/q…

Github.com/IdentityMod…

This paper links: www.cnblogs.com/selimsong/p…

Build an IdentityServer — directory from zero (update…)