Terms and concepts related to authority and authentication system

• authentication Authentication
  Generally speaking, authentication is to verify the identity of the current user , prove “ You are yourself ”（ such as ： You clock in and out every day , All need to be punched by fingerprint , When your fingerprint matches the fingerprint entered in the system , Just hit the card successfully ）

• to grant authorization Authorization
  Authorization , That is, a user grants other applications permission to access certain resources of the user .
  for example , When you install mobile apps ,APP You will definitely jump out and ask if permission is allowed to be granted （ Visit album 、 Location and other permissions ）; When you visit wechat applet , When logging in , The applet asks if permission is allowed （ Get a nickname 、 Head portrait 、 region 、 Personal information such as gender ）
  The ways to achieve authorization are ：cookie、session、token、OAuth

• voucher Credentials
  The premise of authentication and authorization is the need for a medium （ certificate ） To mark the identity of the visitors .
  This is actually a good understanding , Everyone must have ID cards . Pass the ID card , We can apply for mobile cards / Bank card / Personal loans / Transportation, etc , This is the certificate of authentication .
  In Internet applications , Generally, there are two modes of website , Visitor mode and login mode .
  In tourist mode , You can browse the articles on the website normally , Once you want to like / Collection / Share articles , You need to log in or sign up .
  Login mode , When the user logs in successfully , The server will issue a token to the browser used by the user （token）, This token is used to identify you , Every time the browser sends a request, it will bring this token , You can use functions that cannot be used in tourist mode .

• Cookie
  HTTP It's a stateless agreement （ There is no memory for transaction processing , Every time the client and server sessions are completed , The server will not save any session information ）： Each request is completely independent , The server cannot confirm the identity of the current visitor , Can't tell if the sender of the last request is the same person as the sender of this one .
  So the server and browser for session tracking （ Know who is visiting me ）, We must take the initiative to maintain a state , This state is used to tell the server whether the two requests come from the same browser . And this state needs to go through cookie perhaps session To achieve .
  cookie Store on client ：cookie Is a small piece of data that the server sends to the user's browser and stores locally , It is carried and sent to the server the next time the browser makes a request to the same server .
  cookie It's not cross domain ： Every cookie Will be bound to a single domain name , Can't get use under another domain name , The primary domain name and the secondary domain name are allowed to share （ by domain）.

• Session
  session Is another mechanism for recording server and client session states , Usually ,session Is based on cookie Realized ,session Store on the server side ,sessionId Will be stored on the client side cookie in
  session The certification process ：
  When the user first requests the server , The server submits relevant information according to the user , Create the corresponding Session
  Return this Session Unique identification information for SessionID Back to the browser
  The browser receives the SessionID After the message , This information will be saved to Cookie in , meanwhile Cookie Record this SessionID Which domain name does it belong to
  When the user accesses the server for the second time , The request will automatically determine whether the domain name exists Cookie Information , If there is an automatic Cookie Information is also sent to the server , The server will Cookie In order to get SessionID, According to SessionID Find the corresponding Session Information , If not found, the user is not logged in or the login fails , If you find Session Prove that the user has logged in to perform the following operations .
  at present , Most systems verify the login status of users according to this principle .

• Cookie and Session The difference between
  This should be a very frequent question in the interview .
  Security ：Session Than Cookie Security ,Session It's stored on the server side ,Cookie It's stored on the client side .
  The types of access values are different ：Cookie Only string data is supported , Want to set other types of data , It needs to be converted to a string ,Session Can store any data type .
  Different expiry dates ：Cookie Can be set to hold for a long time , For example, we often use the default login function ,Session Short general failure time , Client shutdown （ By default ） perhaps Session Timeout will fail .
  Different storage sizes ： Single Cookie The saved data cannot exceed 4K,Session Storable data is much higher than Cookie, But when there's too much traffic , Will take up too many server resources .

• token Token
  （1）Acesss Token
  Access resource interface （API） Resource credentials required for , Simple token The composition of ：uid( Unique identity of user )、time( Timestamp of current time )、sign（ Signature ,token First few bits of the hash algorithm compressed into a certain length of the hexadecimal string ）
  Acesss Token Is characterized by * The server is stateless 、 Good scalability * Support mobile devices * Security * Support cross program calls
  token The authentication process of is as follows ：
  

Client requests login with user name and password
The server receives the request , To verify the user name and password
After successful verification , The server will issue a token And put this token Send to client
Client received token in the future , Will store it , For example cookie Or localStorage in
Each time the client requests resources from the server, it needs to bring the token
The server receives the request , Then go to verify the client request token , If the validation is successful , Return the requested data to the client
（2）Refresh Token
refresh token Is dedicated to refresh access token Of token.
without refresh token, You can also refresh access token, But every time you refresh, you need to enter the login user name and password , It will be very trouble . With refresh token, Can reduce this trouble , The client directly uses refresh token To update access token, There is no need for users to perform additional operations .

Access Token The validity period of , When Acesss Token Failure due to expiration , Use Refresh Token You can get new Token, If Refresh Token It's not working , The user can only log in again .
Refresh Token And expiration time is stored in the server's database , Only when applying for a new Acesss Token Only when , No impact on business interface response time , I don't need to go to Session Keep it in memory for a lot of requests .

• Token and Session The difference between
  Session It's a mechanism to record the session state between the server and the client , Make the server stateful , Can record conversation information . and Token It's a token , Access resource interface （API） Resource credentials required for .Token Make the server stateless , Session information will not be stored .
  Session and Token Not contradictory , As authentication Token Safety ratio Session good , Because every request has a signature, which can prevent listening and replay attacks , and Session We must rely on the link layer to ensure the communication security . If you need to implement stateful conversations , You can still add Session To save some state on the server side .
  So-called Session Certification is just simple User Store information to Session in , because SessionID The unpredictability of , Consider it safe for the time being . and Token , If it means OAuth Token Or something like that , What is offered is authentication and to grant authorization , Authentication is for users , Authorization is for App . Its purpose is to make App Have access to a user's information . there Token Is the only one. . It can't be transferred to other App On , It can't be transferred to other users .Session Only one simple authentication is provided , That is, as long as there is SessionID , That is to say User All rights of . It needs to be kept strictly confidential , This data should only be stored on the station side , It should not be shared with other websites or third parties App.
  So to put it simply ： If your user data may need to be shared with a third party , Or allow a third party to call API Interface , use Token . If it's always just your own website , Their own App, It doesn't matter what you use .

• JWT（JSON Web Token）
  JSON Web Token（ abbreviation JWT） Is the most popular cross domain authentication solution
  JWT Is a kind of implementation based on the JSON Open standards for （RFC 7519）.JWT The declaration of is generally used to pass the authenticated user identity information between the identity provider and the service provider , To get resources from the resource server . For example, it's used in user login .
  have access to HMAC Algorithm or RSA The public / The secret key is right JWT To sign . Because of the existence of digital signature , These messages are credible .

（1）JWT The certification process ：

User input user name / Password to login , After the server authentication is successful , It will return to the client a JWT
The client will token Save to local （ Usually use localstorage, You can also use cookie）
When a user wants to access a protected route or resource , Need to ask for the head Authorization Use... In the field Bearer Mode add JWT

• Ultra vires loophole
  A vulnerability that exceeds the user's authority but modifies the data and succeeds , It's the ultra vires loophole . It is usually caused by the design defect of permission control function . Ultra vires loopholes can be divided into parallel ultra vires and vertical ultra vires .

Parallel ultra vires ： Means under the same authority , Different users can modify each other or access data , It can also be called horizontal ultra vires .

Vertical ultra vires ： Suppose the user A Permission is lower than user B,A It can be accessed or modified to the user B The data of , Is vertical ultra vires .

** Root causes of ultra vires loopholes ：** Developers are adding to the data 、 Delete 、 Change 、 During the query, the data requested by the client is believed too much, and the judgment of permission is omitted in some steps , Or the parameters submitted by the user are not fully verified , Such as order information 、 Identity information to payment information, etc , Once the permission verification is insufficient , It will easily lead to ultra vires loopholes .

resolvent ：

1、 Interfaces with sensitive data can be added token、cookie And so on , First verify the user's identity , Then perform the corresponding operation .

2、 Important parameters are verified at the back end , Don't trust the parameters from the front end .

3、 You can encrypt the core parameters during transmission , Decrypt at the back end .