Authentication – Login authentication
The article goal
- Three common authentication modes are available
- Session/Cookie
- Token
- SSO (Single sign-on)
The session cookie way
Cookie Principle analysis
Cookie is a unique feature of the browser, that is, every time a request is sent, the cookie header is added to the header, so it can be used to store some information. The backend can Set the cookie to the client by setting the set-cookie request header.
Disadvantages:
- The storage space is insufficient
- Not secure enough, the client can get the cookie
Code implementation: github.com/chaijinsong…
Principle of the session
Because cookies can not put sensitive information, and the storage space is not large enough. So if you think about it in the back end, what you’re storing in a cookie is actually a key, and then the back end receives the request and gets the key through the cookie, and then goes to the session object and gets the value. This saves the user’s status information on the server and prevents the client from accessing sensitive information.
Disadvantages:
- It’s also a stateful service
- For example, redis is used to store the state
- Not flexible:
- What if it’s an APP, where there’s no cookie mechanism, there’s only cookie mechanism in the browser
- What to do across domains
Code implementation: github.com/chaijinsong…
Token
Process review
- When the user logs in, the server generates a token and returns it to the client
- Subsequent requests from the client carry this token
- The server parses the token to obtain user information and responds to user requests
- The token has an expiration date and will be discarded when the client logs out, but no operation is required on the server
Code implementation: github.com/chaijinsong…
JWT(JSON WEB TOKEN) principle analysis
- Bearer tokens contain three components: Token headers, payload, and hashes. To separate
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjoidGVzdCIsImV4cCI6MTU4NTQ5NjY0NCwiaWF0IjoxNTg1NDkzMDQ0fQ.Y2Vst5n9-wFXx_Uh vEIsjRuMiDFOZF-ZqxdAICmA13I
The token header and payload are fixed contents, and the hash value behind them is generated based on the token header and payload+secret. Therefore, if the token header and payload are modified during authentication, the hash value does not correspond to the last hash value, and the authentication fails
SSO SSO
Process:
- When the user accesses the APP system, the APP system requires login, but the user does not log in
- When the SSO login system is displayed, the user login page is displayed
- A user enters the user name and password. After sso authentication, the login status is written to the SSO session and the cookie under the SSO domain name is written to the browser
- After the SSO system login is complete, a token is generated and the SSO system switches to the APP system. Pass token as parameter to app system
- After the APP system obtains the token, it sends a request to the SSO system from the background to verify whether the token is valid
- After the authentication passes, the APP system writes the login status into the session and sets the cookie under the APP domain name
At this point, the cross-domain single sign-on is complete, and the app will be logged in when we visit the app system again. Next, look at the flow when accessing the APP2 system
- When a user accesses app2, the user fails to log in to app2 and switches to SSO
- If a cookie exists under the SSO system domain name after the SSO login page is displayed, the SSO system has been logged in to and re-login authentication is not required
- Sso generates a token, and the browser jumps to App2 and passes the token to App2 as a parameter
- App2 obtains the token and accesses the background SSO to verify whether the token is valid
- After successful authentication, App2 writes the login status to session and sets cookies under app2 domain name
In this way, app2 system does not need to go through the login process, and it is already in the login state.
Code implementation: github.com/chaijinsong…