About
Single Sign-On (SSO, trusted sign-on) is a federation identity application. It's the ability:
- to require a user to sign once
- and gain access to different applications.
SSO is also known as:
- as Trusted sign-on
- or Multi-Domain Security
Characteristics
- just one identity is used
- the applications may choose their method of authentication (session cookie, bearer, …).
Flow
Single sign-on (sso) is conceptually pretty simple 1).
If you know the oauth flows, it's basically a indirect oauth flow, where the authorization point sets its own session cookie.
In this flow, there are:
- The sso server, sso.com
- and two applications:
- domain1.com
- domain2.com
Login on domain1.com
Login on domain1.com
- The user visits domain1.com.
- domain1.com sees that it has no session cookie scoped to the domain domain1.com
- domain1.com redirects to sso.com
- sso.com presents the login page
- Upon successful identification, sso.com redirects back to domain1.com via:
- a callback Url (like domain1.com/ssologin)
- with a session cookie scoped to the domain sso.com
- with a query parameter where the value is:
- the access token encrypted with a shared secret key between domain1.com and sso.com
- or an authorization code that permits to retrieve the access token later
- domain1.com takes:
- the encrypted access token, decrypts it with the shared key.
- or the code, asks the access token to the token endpoint
- domain1 sets its own session cookie for the user with the time out dictated by sso.com.
Next, log in on domain2
- User hits domain2.com and redirects to sso.com
- sso.com already has a cookie for the user, so does not present the login page
- sso.com redirects back to domain2.com with the encrypted information
- domain2.com logs in the user.