I made a single sign-on and encountered a problem: For example, if there are three systems A, B, and C, when there is no login, it will jump to the S system to log in. If the login is successful, a token will be generated and the token will be sent back. At the same time, the token will be stored in redis. But how do systems B and C obtain that token?
I made a single sign-on and encountered a problem: For example, if there are three systems A, B, and C, when there is no login, it will jump to the S system to log in. If the login is successful, a token will be generated and the token will be sent back. At the same time, the token will be stored in redis. But how do systems B and C obtain that token?
After getting this token, use curl or header to send the value to the interfaces of the other two systems B and C respectively. The interfaces GET or POST receive the sent token parameter, and then process this token value. For example, store the token value in redis, session, etc.
Dear, now that you have deposited it into redis, can’t you link B and C to redis and then withdraw it directly from redis
I object to the current best answer. For example, if single sign-on is responsible for logging in to 100 systems, does each system have to request 99 times after a user logs in? What else is called single sign-on?
Other people who say to read tokens directly from redis, do you know which user should read which key?
The so-called single sign-on does not mean that if the user logs in to A, he can also log in to B and C, but that if he logs in to S, he can log in to A, B, and C.
So you need two things:
1. The cookie/session of the S system itself. As long as the user logs in to the S system (whether directly accessing S or accessing S because he wants to log in to A), the cookie/session of the user under the S system will be generated. No need to do anything. Cross-domain processing.
2. Login ticket, the user comes from system A, system S determines whether the user is logged in to system S. If not logged in, it will ask to log in. After logging in or already logged in, a unique ticket will be generated, and the user and The ticket is stored in the database, and then the ticket is returned to system A through the user's browser, and system S allows the user's browser to jump to http://AAA.com/login/callback?ticket=xxxxx. At this time, system A gets the ticket and requests the verification interface of system S internally. System S compares the ticket with the one in the database, finds out the corresponding user information and returns it to system A. System A then knows the user who wants to log in. Who is it?
It is recommended that the subject take a look at the CAS protocol https://apereo.github.io/cas/...
There are many reasons to object to the adopted answer.
First of all, the process of issuing and verifying tickets is wrong (this system usually needs dual-machine hot backup to prevent single point failure, or it is distributed)
As others have said, does it mean that 100 systems push 100? What should I do if there is a timeout or something?
If one system is logged out, other systems should also be logged out?
If the permissions have been modified and only login A is allowed and login B is not allowed, what should I do?
There is no cross-domain problem.
When entering system a, jump to system s.
After the system verifies the account, let the browser jump back to system a with the ticket (in the url parameter).
The a system has received the ticket at this time. The system uses methods such as curl to go to the s system to verify the ticket (you also need to bring the key of your own system to prove the legality of this verification of the a system), if it is Authorize the ticket (even if you log in to the s system, it does not mean that you can log in to the a system. The s system will determine the ticket login permission issued), then let you enter, otherwise it will jump back to the login interface of the s system.
The poster can deploy a certain Java version of the open source single sign-on system to learn the specific usage and process. You can also develop an authorization system such as OAUTH2.0.
b and c provide an interface for obtaining tokens. Once you log in successfully, just refresh it
You can consider using cookies to store and deliver
After the master station completes the login, add the cross-domain code to the page after the login server jumps back, and send it to the slave station (or other sites) at the same time. The code is as follows
<code><script src=xxxx.com?token=aaaaaa> </code>
In this way, you can get the token in xxxx and process the verification
It is recommended to use UCenter or OpenCenter, both of which can easily achieve single sign-on
What the poster means is: 3 systems, I don’t know how to save the sessionid across domains. You can consider UCenter or PHP to use P3P to achieve cross-domain.
Generally, the token is calculated through some encryption algorithm + salt. B and C can use the same encryption algorithm to verify the token when they receive it.
Didn’t the token be transferred back to systems B and C? You can connect to redis directly. The standard point is to put the token on the parameter or header to request the special interface of the S system.
,,,,,,,,,,
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
