Front-end and back-end authentication involves two or three tasks

DevUI is a team with both design and engineering perspectives, serving huawei Cloud DevCloud platform and several huawei internal middle and background systems, as well as designers and front-end engineers. Design Ng Component library: ng-Devui (Welcome Star)

The introduction

Front – and back-end authentication is a big topic. Different organizations have different authentication methods, and even the business implementation of the same protocol may vary widely. This paper tries to describe the authentication in the title from the two dimensions of authentication and authorization, but most of the text is partial to authentication. This article consists of three parts: distinguishing authentication and authorization, common authentication and authorization modes, and single sign-on (SSO) schemes commonly used in enterprise applications.

1 Authentication and authorization

First, let’s take a brief look at authentication and authorization and clarify the difference between the two.

Authentication

Authentication involves an application and a user, and describes the identity of the user in the application. Authentication can simply mean logging in to confirm that you are a legitimate user. The Nuggets, for example, have to be logged in to like and collect.

Authorisation

Authorization involves two applications and one user, and describes the operation rights of a third-party application.

Enter the scenario to distinguish authentication and authorization

To better understand the relationship between authentication and authorization, we will use three examples: authentication only but no authorization, authentication and authorization, and authorization only without authentication.

(1) Only authentication but not authorization

The above mentioned using the nugget account to log in to the nugget is only authentication not authorization scenario, at this time the nugget only knows which user you are, but does not involve authorization operation.

(2) Authentication and authorization

To log in to Nuggets, we can use a third-party application, such as Github, instead of using a registered account and password at Nuggets. A Github login page will be displayed. If you enter your account and password on this page, you will give the digger access to your Github profile picture and account name by default. In this process, you are both authenticated (a legitimate user) and authorized (you are allowing nuggets to access your information from Github).

(3) Not authentication only authorization

Take a take-out applet as an example. When you enter the take-out applet for the first time, the applet will ask for your personal information, which is equivalent to the authentication and authorization mentioned above. After you agree, it is equivalent to logging in with your wechat account, but at this time, your information obtained by takeout mini program does not include your mobile phone number. When you want to place an order click submit, the small program initiates a request again, to get your wechat bound mobile phone number, at this time the action is not authentication only authorization.

2 What are the common authentication and authorization modes?

When it comes to authentication, one issue that must be considered is state management. State management means that after logging into a website for a period of time, you don’t want to have to log in again every time you visit it, so app developers have to think about how to keep users logged in and decide when to lapse. And this process needs to work together on the front and back ends. The following describes several common authentication and authorization modes.

The Session Cookie authentication. –

The session-cookie authentication process is as follows: The user logs in using the user name and password. After the login, the backend saves the user information in the session and writes the session ID to the cookie on the front end. Each subsequent operation is carried to the back end with the cookie.

The main issues developers may face with this method of authentication are as follows:

Cookie security problem, the attacker can get the sessinId in the cookie through XSS, using httpOnly to improve security to some extent
Cookies cannot be transferred across domains
Sessions are stored on the server. Therefore, too many sessions consume large server resources
Session sharing in distributed mode is abnormal

Token authentication

Different from the session-cookie mechanism, token authentication is a stateless authentication mode on the server. The server does not need to store token data, but the server can verify the validity and validity of the token. There are two authentication methods using tokens: SAML and JWT.

SAML (Security Assertion Markup Language)

The process of SAML is as follows:

An unlogged user accesses the Service Provider (SP) website using a browser.
SP detects that the user is not logged in and redirects the page to the Identity Provider (IdP).
After the IdP verifies that the request is correct, it provides a form for the user to log in
After the user logs in successfully, IdP generates and sends the SAML token (a large XML object) to SP
SP authenticates the token, parses and obtains user information, and allows users to access related resources

Add two pieces of information to the above process:

(1) How does SP verify the validity of the token?

For example, is it possible that the token was hijacked and modified during the process from IDP to SP?

The answer is: no. The token returned by IDP to SP is signed by IDP’s private key, and the information signed by the private key can be verified by the corresponding public key.

(2) How does SP determine whether a token has expired?

SAML tokens carry information about the expiration time of the token.

(3) Are the generated SAML tokens hosted in SP or front end?

If it is hosted in SP, then the session mechanism should be introduced. If it is hosted in the front end, then the front end needs to store and pass SAML token every time, but the SAML token size is relatively large, which consumes transmission resources.

The answer is: either. The front-end needs to obtain the token through a separate ajax request and store it in localStorage or other localStorage. If the session is hosted in an SP, then as mentioned above, the front end only knows the session ID and the token mechanism will degenerate into the session-cookie mechanism mentioned above.

JWT (JSON Web Token)

There are many articles about JWT, which will not be covered here. For more information, please refer to Teacher Ruan Yifeng’s introductory article: JSON Web Token Tutorial (estimated reading time: 2mins).

In short, JWT is an authentication and state management method that generates a token after a user logs in and puts the token on the front end. The backend does not need to maintain the state information of the user but can verify the validity of the token.

I don’t want to discuss much of what is already in this article. What I want to talk about is a question that is extended on the basis of this:

Is the secret that JWT uses to sign and verify signatures the same for everyone?

If it is the same, there is a big security risk. Once leaked, all JWT may be decrypted. If not, then you also need to maintain the secret information for each person on the server side, so what is the difference between maintaining session information on the server side?

From the JWT official Introduction document see this sentence:

The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

That is, secret can be used with the server private key. If so, this is the same for all users. If the server private key is lost, then all security is out of the question, so JWT assumes that the private key will not be lost. Of course, as I understand it, developers can also set up a separate secret for each user, which requires the complexity mentioned above.

Here’s an interesting picture of JWT versus SAML

Request authorization

OAuth is designed to be more about authorization than authentication, so the title of this section is authorization, but authentication is done at the same time.

This article is biased towards authentication, OAuth is not discussed here, more OAuth content can refer to this article: Understanding OAuth 2.0

3 the SSO and CAS

Next, we discuss a topic that enterprises should definitely get around: single sign-on.

For example, There are several cloud services under Huawei Cloud. DevCloud (Software development Cloud), which includes many microservices such as project management, code hosting, code review, pipeline, compile and build, deployment, automated testing, etc., is one of them. Users can go to the same place for login authentication when using any of the services without login. After logging in, you can access all other services without logging in for a period of time.

Central Authentication Service (CAS) is a frequently used solution in the sso domain. So here’s how to implement SSO using CAS. The specific implementation of CAS can depend on many kinds of protocols, such as OpenID, OAuth, SAML, etc. Here, WE will focus on the CAS protocol.

Several important concepts in the CAS protocol

This is a brief introduction to some important concepts in THE CAS protocol, which may seem vague at the beginning. You can go through them first and then understand them with the following flowchart.

CAS Server: specifies the central Server used for authentication
CAS Clients: Protects CAS applications and redirects them to the CAS Server for authentication if unauthorized users access them
The TGT & the TGC: After user authentication, the CAS Server generates a Ticket Granting Ticket (TGT) containing user information and writes a cookie (TGC) to the browser
ST: indicates the ticket transmitted as a parameter on the URL. The protected application can use this ticket to go to the CAS Server to check whether the authentication of the user is valid

Core process of the CAS protocol

After the introduction of the concept, combined with the flow chart given by the official (it is better to look at the picture patiently first and then look at the later flow analysis effect), I disintegrated each step in detail, and pointed out several problems that may make people confused.

① The user accesses the home page of the protected application (app_1 for short) using a browser

② The CAS Client on App_1 detects that the user is not authenticated through session detection and redirects the user (for the first time) to the CAS Server. The service parameter in the URL contains the access address of APP_1

③ The CAS Server detects that the user browser does not contain the TGC and provides a form for the user to log in. After the user successfully logs in, the CAS Server generates the TGT containing the user information and writes the TGC to the user browser

TGC is associated with TGT. The user browser directly obtains the ST ticket from the CAS Serv er. If TGC is valid, the user can directly log in without filling in the form information
The expiration policy of TGC is set to 2 hours by default if the user has no page action or background interface request, and 8 hours by default if the user has no page action or background interface request. You can change the expiration time in cas.properties

# most-recently-used expiration policy
cas.ticket.tgt.timeout.maxTimeToLiveInSeconds=7200
# hard timeout policy
cas.ticket.tgt.timeout.hard.maxTimeToLiveInSeconds=28000
Copy the code

(4) The CAS Server redirects the browser (for the second time) back to the home page of App_1, and the REdirected URL contains ST

⑤ When app_1 receives the user’s browser access again, it takes out the ST in the URL parameter of the previous step. With ST, it goes to the CAS Server to confirm whether the current user has completed the authentication. After the CAS Server gives a positive reply, App_1 Remove ST redirection (third redirection) from the URL to the app_1 home page

App_1 (CAS Client) obtains additional information including user information when confirming the current user authentication status from the CAS Server based on the ST
Write this extra information to the session and return the session ID to the front end so that the next time the front end accesses the session, it can determine whether the session is valid or not

⑥ The client browser accesses the app_2 home page under the same authentication system

⑦ Same as step 2, the CAS Client on app_2 detects that the user is not authenticated through session detection and redirects the user to the CAS Server. The service parameter in the URL contains the access address of app_2

(8) The CAS Server detected the TGC of the user’s browser and found the corresponding TGT, which was verified to be valid

⑨ Same as step 4, the CAS Server redirects the browser back to the home page of app_2, and the redirected URL contains ST

⑩ As in step ⑤, app_2 receives the user’s browser access again. App_2 takes out the ST in the URL parameter of the previous step and goes to the CAS Server to confirm whether the current user has completed the authentication. App_2 Remove the ST redirection browser from the URL to the app_2 home page

A few questions about the CAS process

(1) How to avoid sessionId conflict?

The business server (we can think of it as the SAME as the CAS Client mentioned above) guarantees that the user does not need to log in again for a certain period of time by writing the session on the server and passing the session ID back to the front-end store. How to ensure that the sessionids of sub-services using the same single point of authentication (hereinafter described as service A and service B) do not conflict? Of course, this problem assumes that service A and service B are not using a shared session.

If service A and service B are using a shared session, then their session ids must be the same, that is, the CAS clients of both services are the same session in the above process (2). At this point, if the user has logged in to service A, he can directly access service B, because the login status has been verified in step 2.

If service A and service B do not use a shared session, then the user needs to go through step (8) of the above process to confirm that the user is logged in. In this case, the user still does not need to log in, but the authentication process is much longer than the shared session. If you look at all the requests in the network, you’ll also see that a few more 302s were added in the process. The question discussed here is exactly how a and B can avoid sessionId conflicts in this situation.

Once a conflict occurs, the CAS clients of both parties need to continuously confirm and refresh the session on the CAS Server when the user switches between A and B. If the description of this paragraph is not easy To understand, you can read the “First Access To Second Application” section of the flowchart above again. To avoid conflicts, a and B each prefix the key they write to the front cookie with the service name, such as a_sessionId and b_sessionId, respectively.

(2) Assuming that A and B use the same sso authentication Server, is it possible that application A’s login expires while application B’s does not?

If a and B are not using a shared session, is it possible that the authentication status of a’s application has expired (neither session nor TGC is valid) while b’s application has not expired (at least one session or TGC is valid)?

The answer is: no. In service implementation, the CAS Client communicates with the CAS Server regularly. If the user keeps operating, the CAS Server extends the expiration time of the TGC. In the end, the expiration time of the TGC must be the same for A and B. Therefore, even if the expiration duration of the sessions on both sides is different, the authentication status can go to the CAS Server at most and pass the TGC detection, so that a does not need to log in and B does not need to log in.

conclusion

This paper first discusses the difference between authentication and authorization, and lists several common authentication and authorization methods. Then it mainly introduces the process and problems of using CAS protocol to realize single sign-on. Finally, one additional point. Huawei Cloud DevCldoud CAS Client is a reference to the standard CAS protocol implementation, interested students can register an account here, and then open F12 use the account to log in to observe all network requests and analyze the complete process of CAS service implementation.

Join us

We are DevUI team, welcome to come here and build elegant and efficient man-machine design/R&D system with us. Recruitment email: [email protected].

The text/DevUI east less

Refer to the article

JWT: juejin. Im /post/684490
SAML:www.cnblogs.com/maxigang/p/…
Understand the 2.0 :www.ruanyifeng.com/blog/2014/0…
JSON Web Token introductory tutorial: www.ruanyifeng.com/blog/2018/0…
Introduction to JSON Web Tokens jwT. IO/Introductio…
SAML2.0 start guide: www.jianshu.com/p/636c1ee16…
The CAS protocol: apereo. Making. IO/CAS / 4.2 x/p…
CAS Properties: apereo. Making. IO/CAS / 5.0 x/I…
Ticket Expiration Policies: apereo. Making. IO/cas / 4.2 x/I…

Previous article recommended

VSCode Plug-in DevUIHelper design and development overview (1)

Dark Patterns and Thematic Development for Web Interfaces

How to Build a Grayscale Publishing Environment