The fastest shortcut in the world , It's down to earth , This article has been included 【 Architecture technology column 】 Focus on this place where you like to share .
introduction
Front end authentication is a big topic , Different organizations have different authentication methods , Even the business implementation of the same protocol may be quite different .
This paper attempts to describe the authentication in the title from the two dimensions of authentication and authorization , Most of the space is still partial authentication .
The article mainly includes three parts ：
- Distinguish between authentication and authorization
- Common authentication and authorization methods
- Common single sign on in enterprise applications （SSO） programme .
1 Certification and authorization
First , Let's take a brief look at authentication and Authorization , And sort out the difference between the two .
- authentication （Authentication）
Authentication involves one application and one user , It is used to describe the identity of the user under the application . Authentication can be simply understood as login , To confirm that you are a legitimate user . For example, the Nuggets have to log in to like it 、 Collection .
- to grant authorization （Authorisation）
Authorization involves two applications and one user , It is used to describe the operation permissions of third-party applications .
Bring in scenarios to distinguish authentication from authorization
Let's give three examples to illustrate the three situations, so that we can have a better understanding of the relationship between authentication and authorization ：
- Only authentication, not authorization
- Both authentication and authorization
- No authentication, only authorization
（1） Only authentication, not authorization
The above-mentioned use of nuggets account to log in to Nuggets is only authentication without authorization , At this time, Nuggets only knows which user you are , But it doesn't involve authorized operations .
（2） Both authentication and authorization
It's the same as logging into the Nuggets , We can log in without using the account and password registered with nuggets , And choose a third-party application to log in , for instance github account number .
It will pop up github Login page for , If you enter your account and password on this page to login , It's equivalent to granting the Nuggets permission to get your github Your avatar and account name .
In this process, the authentication is completed （ Legal users ） It's authorized again （ You allowed the Nuggets to go from github Get your information ）.
（3） No authentication, only authorization
Take a takeaway app as an example , The first time you enter the takeaway app, the app will pop up a box and ask for your personal information , This is equivalent to the above mentioned authentication and authorization .
After you agree, it is equivalent to using wechat account to log in , But at this time, the takeaway app gets your information that doesn't include your mobile phone number .
When you want to place an order, click Submit , The applet initiates the request again , To get your wechat bound mobile phone number , What happens at this point is not to authenticate, only to authorize .
2 What are the common authentication and authorization methods ？
Once certification is involved , One problem that must be considered is state management .
The so-called state management is a period of time after we log in to a website , You don't want to log in again every time you visit it , So the application developer must consider how to keep the user's login status and decide when to fail .
And this process needs the cooperation of the front and back end . Here are some common authentication and authorization methods .
Session-Cookie authentication
（1） technological process
Session-Cookie The authentication process is as follows ： The user first logs in with a user name and password , After the login is completed, the user information will exist in the back end session in , hold sessionId Write to the front cookie in , Every operation in the back has cookie To the back end , As long as the back-end judges sessionId No problem and no expiration, you don't need to log in again .
Authentication in this way , The main problems developers may face are as follows ：
- cookie Security issues , Attackers can get through xss obtain cookie Medium sessinId, Use httpOnly Improve security to a certain extent
- cookie Can't transfer across domains
- session Stored in the server , therefore session Too much will consume more server resources
- Distributed session Sharing issues
Token authentication
With the above Session-Cookie The difference in the mechanism is , be based on token User authentication is a stateless authentication method of the server , The server does not need to store token data , But the server can verify token The legitimacy and effectiveness of .
Use token There are two ways of authentication ：
- SAML
- JWT
SAML (Security Assertion Markup Language)
SAML The process is as follows ：
- Users who are not logged in visit the resource website through the browser （Service Provider, abbreviation SP）
- SP Found user not logged in , Redirect the page to IdP（Identity Provider）
- IdP After verifying that the request is correct , Provide a form for users to log in
- After the user logs in successfully ,IdP Generate and send SAML token ( A big one XML object ) to SP
- SP Yes token To verify , Parsing to get user information , Allow users to access related resources
Add two information to the above process ：
（1）SP How to verify token Legitimacy ？
For example, is it possible to token stay IDP To SP In the process of hijacking and modifying the content ？
The answer is ： stand no chance . because IDP Return to SP Of token Use IDP The private key of the , The information signed by the private key can be verified by the corresponding public key .
（2）SP How to determine token Is it overdue ？
SAML token With token Expiration time information .
（3） Generated SAML token It's hosted in SP Or the front end ？
If it's hosted in SP, Then we have to introduce session Mechanism , If hosted on the front end , So the front end needs to store and deliver every time SAML token, however SAML token It's bigger , Consuming transmission resources .
The answer is ： Fine . If you put it on the front end, you need the front end to go through a separate ajax The request for token And stored in localStorage Or other local storage . If it's hosted in SP, So, like the above , introduce session, The front end only controls sessionId, In this case token The mechanism actually degenerates into the one mentioned above session-cookie Mechanism .
JWT（JSON Web Token）
About JWT There are many articles about , No more details here , Related information can refer to Ruan Yifeng teacher's introductory article ：JSON Web Token Introductory tutorial （ Estimated reading time ：2mins）
in short ,JWT It is generated after the user logs in token And put token Put it on the front , The back end does not need to maintain the user's state information, but can verify token Effective authentication and state management .
There are already some contents in the article, but I don't want to discuss them here , What I want to talk about is a problem that extends from this foundation ：
JWT Used to sign and verify signatures secret Is it the same for all people ？
If it is the same, there is a big security risk , In case of leakage , all JWT Could be decrypted . If it's not the same , Then, it is also necessary to maintain the corresponding of each person on the server side secret Information , In this way, the server-side maintenance session What's the difference between information ？
from JWT official Introduction We can see such a sentence in the introduction document of ：
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 You can use the server private key . If so , It's the same for all users . If the server private key is lost , There's no way to talk about safety , therefore JWT It is assumed that the private key will not be lost . Of course, as I understand it , Developers can also set up a separate secret, This has to face the complexity problem mentioned above .
About JWT and SAML Comparison of , There's an interesting picture
OAuth to grant authorization
OAuth Is designed to be authorized rather than authenticated , So the title of this section says Authorization , But in fact, authentication has been completed at the same time as authorization .
This article is biased towards authentication ,OAuth I don't want to talk about it here , more OAuth The content can refer to this article ： understand OAuth 2.0
3 SSO And CAS
Next, we will discuss a topic that enterprises must not be able to bypass ： Single sign on .
for instance , There are several cloud services under Huawei cloud . Including project management 、 Managed code 、 Code checking 、 Assembly line 、 Compiling and constructing 、 Deploy 、 Automated testing and many other micro services DevCloud（ Software development cloud ） It's one of them , Users can go to the same place for login authentication when using any service without logging in , After logging in, you can access all other services without logging in for a period of time .
In the realm of single sign on ,CAS（Central Authentication Service, The Chinese name is the central certification service ） It's a high-frequency solution . therefore , Here's how to use CAS Realization SSO. and CAS The specific implementation of can rely on a variety of protocols , such as OpenID、OAuth、SAML etc. , Here's a brief introduction CAS agreement .
CAS Several important concepts in the agreement
A brief introduction CAS Several important concepts in the agreement , At first, the concept may be vague , You can go through it first , Then combine the following flow chart to understand .
- CAS Server： Central server for authentication
- CAS Clients： Protect CAS application , Once there is an unauthorized user accessing , Redirect to CAS Server authentication
- TGT & TGC： After user authentication ,CAS Server Generate a user information TGT (Ticket Granting Ticket) And write a cookie（TGC,Ticket Granting Cookie）, What's the use? I'll talk about it later
- ST： stay url As a parameter ticket, Protected applications can rely on this ticket Go to CAS Server Confirm whether the user's authentication is legal
CAS The core process of the agreement
After introducing the concept , Combined with the official flow chart （ First look at the diagram patiently, and then look at the following process analysis effect is better ）, Each step is disassembled in detail , And point out a few questions that may be confusing .
① Users access protected apps through browsers （ hereinafter referred to as app_1） home page
② app_1 On the side CAS Client By testing session To detect that the user is not authenticated , Redirect users （ The first redirection ） To CAS Server,url The parameters carried on the service Contains app_1 Access address of
③ CAS Server Detected no user browser TGC, Provide a form for users to log in , After the user logs in successfully ,CAS Server Generate... That contains user information TGT, And write TGC To the user browser
- TGC Follow TGT Related to , It's the user's browser that goes directly to CAS Serv er obtain ST The paper , If TGC It works , The user does not need to complete the steps of filling in the form information to directly login
- TGC The expiration policy of is set as follows , If the user has no page operation and background interface request , So default 2 Hours expired , If there is always an operation , Default 8 Hours expired , Developers can use the cas.properties Modify these two expiration dates in , The general application will not configure such a long expiration time
#most-recently-used expiration policy
cas.ticket.tgt.timeout.maxTimeToLiveInSeconds=7200
#hard timeout policy
cas.ticket.tgt.timeout.hard.maxTimeToLiveInSeconds=28000④ CAS Server Redirect the browser （ The second redirection ） return app_1 home page , At this point, the redirection of url With ST
⑤ app_1 Receive access to the user's browser again , Take the last step url In the parameter ST Take it out , With ST Go to CAS Server Confirm whether the current user has completed authentication ,CAS Server After giving a positive reply ,app_1 Remove url Upper ST Redirect （ The third redirection ） Browser to app_1 home page
- app_1（CAS Client） rely on ST Whereabouts CAS Server Additional information including user information is obtained while confirming the current user authentication status
- Write the extra information to session In and out sessionId Back to the front end , The next time the front-end visits, it will directly judge session Whether it works is OK
⑥ Client browser to access under the same authentication system app_2 home page
⑦ Same as ② Step ,app_2 On the side CAS Client By testing session To detect that the user is not authenticated , Redirect users to CAS Server,url The parameters carried on the service Contains app_2 Access address of
⑧ CAS Server Detected user browser's TGC, Find the corresponding TGT, It's proven to be legal , This is the echo of the ③ Step by step TGC
⑨ Same as ④ Step ,CAS Server Redirect the browser back to app_2 home page , At this point, the redirection of url With ST
⑩ Same as ⑤ Step ,app_2 Receive access to the user's browser again , Take the last step url In the parameter ST Take it out , With ST Go to CAS Server Confirm whether the current user has completed authentication ,CAS Server After giving a positive reply ,app_2 Remove url Upper ST Redirect browser to app_2 home page
About CAS Several problems in the process
（1） How to avoid sessionId Conflict ？
Business server （ We might as well regard it as the following CAS Client It's a thing ） By writing on the server side session And the sessionId Return to the front end to save the way , Ensure that users do not need to log in again for a period of time .
So how to ensure that each sub service using the same single point of Authentication （ The following is to serve a And the service b To give an example of ） Of course sessionId No conflict ？ Of course, the premise of this problem is service a And the service b No use of sharing session The situation of .
If the service a And the service b Using sharing session, So their sessionId It must be consistent , That is, both CAS Client In the above process ② It was detected in session It's consistent . At this point, if the user is already serving a Sign in , Then you can directly access the service b, Because in the first place ② The login status has been verified in step 1 .
If the service a And the service b No use of sharing session, So the user is serving a After login , Then visit the service b, Go to the first step of the above process ⑧ Step to confirm that the user is logged in , here , Users still don't need to log in to access , But the validation process is compared to sharing session A lot longer , If you look at network All requests in , You'll also find a few more in the process 302.
The problem to be discussed here is precisely in this case a and b How to avoid sessionId Conflict .
In case of conflict , Will cause users to be in a and b When switching between , The two sides of the CAS Client You need to keep going CAS Server Confirm and refresh session.
If the description in this paragraph is not easy to understand , You can go up and look at the flow chart above again 【First Access To Second Application】 part .
It's easy to avoid conflict , namely a and b Each writes its own front end cookie Of key Add service name as prefix on , For example, they are written separately as a_sessionId and b_sessionId.
（2） hypothesis a And b Use the same single sign on Authentication Server, Is it possible that a Application login expired ,b There is no expiration of the app ？
Then the above questions are discussed ,a and b Without sharing session Under the circumstances , Is there any possibility of such a situation ：a The authentication status of the application has expired （session and TGC All invalid ） and b The app hasn't expired yet （session or TGC There is at least one valid ）？
The answer is ： Can't . In business implementation ,CAS Client I will talk to you regularly CAS Server communicate , If the user has been operating , that CAS Server It will be extended accordingly TGC The expiration time of , Finally, for a and b Come on ,TGC The expiration time of must be the same .
So even on both sides session Set expiration time inconsistent , The authentication status is up to CAS Server Through TGC We can do it , They don't show up a Need to log in ,b No need to log in .
summary
This paper first discusses the difference between authentication and authorization , Several common authentication and authorization methods are listed . Then it focuses on the use of CAS The process and problems of single sign on protocol . Last , add .
Hua Wei Yun DevCldoud Of CAS Client It's the reference standard CAS Protocol implementation , Those of you who are interested can ad locum Create an account , Then open the F12 Log in with an account, observe all network requests and analyze CAS The complete process of business implementation .
author ： DevUI It's a team with both design and engineering perspectives , Serve Huawei cloud DevCloud The platform and Huawei's internal several middle and background systems , For designers and front-end Engineers .
Official website ：devui.design
