The fastest shortcut in the world is to keep your feet on the ground. Focus on the sharing place.

The introduction

Front-end and back-end authentication is a big topic. Different organizations use different authentication methods, and even the business implementations of the same protocol may differ greatly.

This paper tries to describe the authentication in the title from two dimensions of authentication and authorization, and most of the text is partial authentication.

This article mainly includes three parts:

  • Distinguish between authentication and authorization
  • Common authentication and authorization methods
  • Single sign-on (SSO) schemes are common in enterprise applications.

1 Authentication and Authorization

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

  1. Authentication

    Authentication involves an application and a user, and describes the user’s identity under the application. Authentication can be simply interpreted as logging in to confirm that you are a legitimate user. Nuggets, for example, must be logged in to like and favorites.

  2. Authorisation

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

Enter scenarios to distinguish authentication and authorization

Let’s give three examples to illustrate three situations to give you a better understanding of the relationship between authentication and authorization:

  • Authentication only, not authorization
  • Authentication and authorization
  • No authentication, only authorization

(1) Authentication only, not authorization

The above mentioned use of nuggets account login nuggets is only authentication without authorization scenario, nuggets at this time only know which user you are, but does not involve authorization operations.

(2) both authentication and authorization

To log in to Nuggets, we can choose to log in to third-party applications, such as Github account, without using the account and password registered in Nuggets.

The github login page will pop up. If you enter your account and password to log in, you will be authorized to obtain your Github profile picture and account name by default.

In this process, you complete both authentication (legitimate user) and authorization (you allow nuggets to access your information from Github).

(3) Authorization only without authentication

Take a small program for example, when you enter the small program for the first time, the small program will pop a box to request to obtain your personal information, which is equivalent to the authentication and authorization mentioned above.

If you agree to use your wechat account to log in, however, your information obtained by the food delivery mini program does not include your mobile phone number.

When you click submit to place an order, the small program will initiate a request again to obtain 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?

Once authentication is involved, one issue that must be considered is state management.

State management means that we don’t want to have to log in again every time we visit a website after logging in for a period of time, so application developers must consider how to keep users logged in and decide when to break down.

This process requires both the front and back ends to work together. The following describes common authentication and authorization methods.

The Session Cookie authentication. –

(1) Process

The session-cookie authentication process is as follows: The user logs in with the user name and password first. After login, the back-end saves the user information in the session and writes the sessionId into the cookie in the front end. Each subsequent operation takes the cookie to the back-end end.

The main issues developers may face with this approach to authentication are as follows:

  • The attacker can obtain the sessinId in the cookie through XSS, and use httpOnly to improve security to a certain extent
  • Cookies cannot be transferred across domains
  • Sessions are stored on the server. Therefore, too many sessions consume large server resources
  • Session sharing problem in distributed mode

Token authentication

Different from the session-cookie mechanism, token-based user 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.

The following two authentication methods are used:

  • SAML
  • JWT

SAML (Security Assertion Markup Language)

SAML flows as follows:

  • An unlogged user accesses a resource website (SP) through a browser.
  • SP finds that the user is not logged in and redirects the page to Identity Provider (IdP).
  • After the IdP verifies the request, 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 tokens, parses and obtains user information, and allows users to access related resources

Two pieces of information are added to the above process:

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

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

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

(2) How does SP judge whether token is expired?

The SAML token carries information about the token expiration time.

(3) Is the generated SAML token hosted in SP or front-end?

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

The answer is: both. To put it on the front end, the front end needs to fetch the token through a separate Ajax request and store it in localStorage or some other local store. If it is hosted in SP, then as mentioned above, the session is introduced, and the front end only holds the sessionId, then the token mechanism actually degenerates into the session-cookie mechanism mentioned above.

JWT – JSON Web Token

There are many articles about JWT, which will not be described here. For more information, please refer to Ruan Yifeng’s introduction to JSON Web Token.

In short, JWT is an authentication and status management method that generates tokens after user login and puts them in the front end. The back end does not need to maintain user status information but can verify the validity of tokens.

The content already in the article is not discussed here, but what I want to talk about is a problem extended on this basis:

Is JWT’s secret for signing and verifying signatures the same for everyone?

If they are the same, there is a big security risk, once leaked, all JWT may be decrypted. If not, then the secret information corresponding to each person needs to be maintained on the server side. In this case, what is the difference between maintaining session information on the server side?

From the official JWT Introduction document, you can see the following 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.

In other words, secret can use the server private key. If so, it is the same for all users. If the server private key is lost, all security is lost, so JWT assumes that the private key is not lost. Of course, as I understand it, developers could also set up a separate Secret for each user, which would have to deal with the complexity mentioned above.

There is 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 says authorization, but authentication is done at the same time as authorization.

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

Let’s take a look at a topic that companies should be sure to beat: single sign-on.

For example, Huawei cloud has several cloud services. DevCloud, which includes project management, code hosting, code review, pipelining, build, deployment, automated testing and many other microservices, is one of them. Users can go to the same place for login authentication if they are using any of the services without logging in. After login, you can access all other services without logging in for a period of time.

Central Authentication Service (CAS) is a frequently used solution in single sign-on (SSO). So, here’s how to implement SSO using CAS. The specific implementation of CAS can rely on a variety of protocols, such as OpenID, OAuth, SAML, etc. The CAS protocol is mainly introduced here.

Several important concepts in CAS protocol

This section briefly introduces some important concepts in the CAS protocol. These concepts may be vague at first. You can go through them first and then use the following flowchart to understand them.

  • CAS Server: the central Server for authentication
  • CAS Clients: protects CAS applications. Access by unauthenticated users is redirected to the CAS Server for authentication
  • The TGT & the TGC: After a user is authenticated, the CAS Server generates a Ticket Granting Ticket (TGT) containing user information and writes a Ticket Granting cookie (TGC) to the browser
  • ST: indicates the ticket transmitted as a parameter in the URL. The protected application can send the ticket to the CAS Server to check whether the user authentication is valid

Core CAS process

After introducing the concept, take a detailed breakdown of each step and point out a few questions that may make people confused with the official flow chart (read the diagram patiently first and then see the process analysis effect later is better).

① A user accesses the home page of the protected application (APP_1 for short) through a browser

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

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

  • The TGC is associated with the TGT. The user browser directly obtains the TICKET of ST from the CAS server. If the TGC is valid, the user can directly log in without completing the steps of filling in the form information
  • TGC’s expiration policy is set in such a way that the default expiration time is 2 hours if there is no page action or background interface request, and 8 hours if there is no action. Developers can change these two expiration times 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

④ The CAS Server redirects the browser (the second redirection) back to the app_1 home page. In this case, the redirected URL contains ST

⑤ App_1 receives the access from the user’s browser again, takes ST out of the url parameter in the previous step, and sends the ST to the CAS Server to verify whether the current user is authenticated. After the CAS Server sends a positive reply, App_1 removes the ST redirection (third redirection) browser from the URL to the app_1 home page

  • App_1 (CAS Client) obtains additional information including user information when checking the current user authentication status from the CAS Server using the ST
  • Write this extra information to the session and return the sessionId to the front end so that the front end can determine whether the session is valid the next time it accesses it

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

⑦ As in step 2, the CAS Client on the APP_2 side detects that the user is not authenticated by detecting the session and redirects the user to the CAS Server. The service parameter in the URL contains the access address of APP_2

The CAS Server detects the TGC of the user’s browser and finds the corresponding TGT, which is verified to be valid, echoing the TGC of step 3

⑨ As in step ④, CAS Server redirects the browser back to the home page of APP_2, where the redirected URL carries ST

⑩ As in step 5, APP_2 receives the access from the user’s browser again. It takes ST out of the url parameter in the previous step and sends the ST to the CAS Server to verify whether the user has been authenticated. App_2 removes the ST redirect browser from the URL to the app_2 home page

Several questions about the CAS process

(1) How to avoid sessionId conflict?

By writing a session on the server and sending the sessionId back to the front end for storage, the business server ensures that the user does not need to log in again for a certain period of time.

How to ensure that the sessionids of the sub-services using the same single point of authentication (service A and service B are described below as examples) do not conflict? Of course, the premise of this problem is that service A and service B do not use a shared session.

If service A and service B use a shared session, their sessionids must be the same. That is, the CAS clients of service A and service B detect the same session in process 2. If the user is already logged in to service A, then he can directly access service B because the login status was verified in step 2.

If service A and service B do not use a shared session, then the user needs to go through the eighth step in the above process to confirm that the user has logged in to service B after service A has logged in. At this point, the user still does not need to log in to access service B, 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 a few extra 302s in the process.

The question to discuss here is exactly how a and B avoid sessionId conflicts in this case.

If a conflict occurs, the CAS clients of both parties need to continuously confirm and refresh the session on the CAS Server when users switch between USER A and USER B.

If the description in this paragraph is not easy To understand, you can scroll up and look again at the “First Access To Second Application” part in the flowchart above.

In fact, it is also very simple to avoid conflicts. That is, A and B prefix the keys they write into front-end cookies with service names, such as a_sessionId and b_sessionId respectively.

(2) Assuming that A and B use the same single sign-on authentication Server, is it possible that the login of application A expires while that of application B does not?

If a and B do not use a shared session, is it possible that the authentication status of a application has expired (both session and TGC are invalid) while that of B application has not expired (at least one session or TGC is valid)?

The answer is: no. In the service implementation, the CAS Client periodically communicates with the CAS Server. If a user keeps performing operations, the CAS Server extends the EXPIRATION time of a TGC. In the end, the EXPIRATION time of a TGC must be the same for A and B.

Therefore, even if the session expiration duration on the two ends is different, the authentication can be completed only after the CAS Server passes the TGC detection. User A does not need to log in to user B.

conclusion

This paper first discusses the difference between authentication and authorization, and lists several common authentication and authorization methods. Then it introduces the process and problems of using CAS protocol to realize single sign-on. Finally, one more thing.

The CAS Client of Huawei Cloud DevCldoud is the reference standard CAS protocol implementation. Interested students can register an account here, then open F12 and log in with the account to observe all network requests and analyze the complete process of CAS service implementation.

DevUI is a team with both design and engineering perspectives, serving huawei Cloud DevCloud platform and huawei internal background systems, as well as designers and front-end engineers.

Official website: devui.design