Single Sign-on realization idea

2015/9/22 22:35:50

Often we use single sign-on scenarios where multiple apps need to share the user's underlying information and login status
2015/9/22 22:37:07
Several applications need to take into account such situations
1. Same primary domain
2. Cross-domain
2015/9/22 22:41:17
I will analyze the use scenes of single sign-on, the characteristics of the scene, the methods of implementation, the problems encountered,
2015/9/22 22:42:29
After the user logs in, we will record his login status.
2015/9/22 22:43:26
Collect basic information (such as browser, IP access time) and set some parameters (ticket expiration time), generate ticket according to the corresponding rules
Here's the ticket as the next time the user accesses the protected resource (the URL that needs to be signed in)
What are the characteristics of ticket
2015/9/22 22:44:34
Timeliness, so here in the persistence, you can not select the database first, and select the cache
Here's a section on ticket.
2015/9/22 22:45:24
Calibration for ticket
When a user accesses each protected resource, we need to verify the ticket he is carrying.
See if ticket is valid, expired
2015/9/22 22:46:23
Check can be divided into the client-side checksum, and the server check two ways
23:07:13
Here will be a single sign-on system, split into client + server two parts, the client in the form of jar package, the service end of the service form reflected
23:09:44
When the user logs on for the first time, the ticket is generated, stored in the front session (distributed cache), and the backend is persisted.
23:10:44
Depositing ticket into a cookie
Checksums are divided into two types (form and asynchronous requests, get requests)
23:12:31
Get requests, which can be compared to the cookie-session cookie backend via the client's interceptor
Asynchronous request, through the front-end Package JS SDK, unified Portal, in turn cookie-session cookie-ticket value in the backend
23:14:10
Get request, for users who need to log in, can make a page jump, and give the corresponding back-jump link
Asynchronous request, on the current access page, draw a frame for login verification
23:07:13
Here will be a single sign-on system, split into client + server two parts, the client in the form of jar package, the service end of the service form reflected
23:09:44
When the user logs on for the first time, the ticket is generated, stored in the front session (distributed cache), and the backend is persisted.
23:10:44
Depositing ticket into a cookie
Checksums are divided into two types (form and asynchronous requests, get requests)
23:12:31
Get requests, which can be compared to the cookie-session cookie backend via the client's interceptor
Asynchronous request, through the front-end Package JS SDK, unified Portal, in turn cookie-session cookie-ticket value in the backend
23:14:10
Get request, for users who need to log in, can make a page jump, and give the corresponding back-jump link
Asynchronous request, on the current access page, draw a frame for login verification

Single Sign-on realization idea