PHP single sign-on

I encountered A single-point logon problem: for example, if A, B, and C systems are not logged on, they will jump to the S system to log on, and A token will be generated when the logon is successful, pass the token back, and store the token in redis. But how does the system B and C obtain the token? I encountered A single-point logon problem: for example, if A, B, and C systems are not logged on, they will jump to the S system to log on, and A token will be generated when the logon is successful, pass the token back, and store the token in redis. But how does the system B and C obtain the token?

Reply content:

I encountered A single-point logon problem: for example, if A, B, and C systems are not logged on, they will jump to the S system to log on, and A token will be generated when the logon is successful, pass the token back, and store the token in redis. But how does the system B and C obtain the token?

Get thistokenAnd then useCurlOrHeaderTo send the values to the interfaces of the other two B and C systems.GETOrPOSTReceive senttokenParameter, and then process the token value. For example, store the token value to redis and session.

You have saved all of them nowredisNow, link B and CredisAnd then directlyredisCan it be Retrieved?

Against the current best answer, for example, if single-point logon is responsible for logging on to 100 systems, will every system request 99 times after a user logs on? What is single sign-on.

Other people who read tokens directly from redis, do you know which user reads which key?

The so-called single sign-on does not mean that the user can log on to B and C after logging on to A, but can log on to A, B, and C after logging on to S.

So we need two things:

1. the cookie/session of the S system, as long as the user logs on to the S system (whether directly accessing S or accessing S because he wants to log on to ), generate the cookie/session of the user in the S system without any cross-domain processing.
2. login ticket: the user comes from System A. The S system determines whether the user has logged on to the S system. if the user has not logged on to the S system, the user is required to log on, A unique ticket will be generated to store the user and ticket in the database, and then the ticket will be returned to system A through the user's browser, and the S system will let the user's browser jumphttp://AAA.com/login/callback?ticket=xxxxx. At this time, system A obtains ticket and internally requests the verification interface of system S. system S compares the ticket with the database to find the information of the corresponding user and return it to System, system A knows who the user is to log on.

Suggest the subject to look at the CAS protocol https://apereo.github.io/cas...

There are N reasons to reject the answer.
The process of issuing and verifying tickets is incorrect first (this system usually requires dual-host hot backup to prevent single point of failure or distributed backup)
As others have said, 100 systems have difficulties in pushing 100 systems? Timeout or something?
If one system logs out, should other systems also log out?
If the permission is modified, only logon to A is allowed, and logon to B is not allowed. how can this problem be solved?

There is no cross-origin issue.

1. Go to System a and jump to system s.

2. After the s system verifies the account, let the browser jump back to system a with the ticket (in the url parameter.

3. System a is introduced into the ticket at this time,The system uses methods such as curl to verify the ticket of the s system (the validity of the verification is also verified by the key of the system and so on)If it is an authorization ticket (even if you have logged on to the s system, it does not mean you can log on to the system. Specifically, the s system determines the permission to log on to the issued ticket, otherwise, the system will jump back to the logon interface of the s system.

You can deploy a java open-source single sign-on system to learn the specific usage and procedures. You can also perform authorization systems such as OAUTH2.0.

B, c provides an interface for obtaining tokens. after successful login, you can click it.

You can use cookies to store and transmit data.

After logging on to the main site, add the cross-origin code to the page after the login server jumps back and send it to the slave site (or other sites). The code is as follows: