Single Sign-On (SSO)

Here’s how single sign-on (SSO) works:

1. User visits an app system that requires login. The user is not logged in yet.

2. The system redirects to the CAS server (SSO login system). We’ll call this the SSO system from now on. The SSO system also has no login, so it shows the user login page.

3. The user enters username and password. The SSO system authenticates them and writes the login status to its session. It also sets a cookie under the SSO domain in the browser.

4. After login, the SSO system generates an ST (Service Ticket). It then redirects back to the app system and passes the ST as a parameter.

5. The app system takes the ST and sends a request to SSO in the background to verify if the ST is valid.

6. After verification, the app system writes the login status to its session and sets a cookie under the app domain.

Now cross-domain single sign-on is complete. When we visit the app system again, we’re already logged in. Let’s see what happens when we access app2.

1. User visits app2. App2 needs login, so it redirects to SSO.

2. SSO is already logged in. No need to authenticate again.

3. SSO generates an ST. The browser redirects to app2 with the ST as a parameter.

4. App2 gets the ST and checks with SSO in the background to validate it.

5. After validation, app2 writes the login status to its session and sets a cookie under the app2 domain.