How does SSO (Single Sign On) work

Well, there are certainly many ways to achieve it, and it can be tricky. I can give you one solution as an example:

Consider two apps on different subdomains:

The Fine Corinthian Turkey Shop (turkey.example.com)
Rent a Baboon (monkey.example.com)

These two web apps want to share signon, and arrange for a third hosted website for their single sign-on:

sso.example.com

Then the flow is:

  1. Frank visits http://turkey.example.com/orders/12
  2. Turkey redirects to https://sso.example.com/login
  3. SSO presents user with login form, validates and issues token
  4. The token is saved in a cookie on SSO.
  5. User is now validated on SSO, but needs to get the token back to turkey.
  6. SSO stores a combination of (Guid, Token, Expiry) on the server, where Guid is a random guid and Expiry is something like 30 seconds.
  7. SSO sets a secure cookie on *.example.com containing the Guid
  8. SSO redirects back to http://turkey.example.com/orders/12
  9. Turkey can now retrieve the ticket from the cookie
  10. Turkey calls SSO server and exchanges the ticket for the token.
  11. Turkey stores token in the browser (typically a cookie)

Now let’s imagine that Frank wants some nice juicy baboons to go with that turkey:

  1. Frank visits: http://monkey.example.com/order-in-bulk
  2. Monkey sees that Frank has no stored token and redirects to https://sso.example.com/login
  3. SSO sees that Frank is already logged in as he has a stored token.
  4. SSO stores a new (Guid, token, expiry) triple on the server
  5. Process is identical to the initial login the rest of the way

Leave a Comment