How does SSO (Single Sign On) work

Question

I'm trying to wrap my head around SSO. It's my understanding that SSO allows you to login once and get access to multiple apps (if you have rights). So, I log into App A. I establish a token. How does that token become available to App B so I do not have to login to App B again (assuming user has rights to A and B)? My Apps are AngularJs apps. I access .Net WebAPis for data.

I can see if I login to App A and retrieve a token then launch App B from App A by passing the token to App B. This way App B has the token and can send to server to make sure user has access to B. However, if user opens a browser directly and goes to App B, then how does their session get established with existing token?

If the answer is there's session state on the back-end server, then how does session state match the user logged in App A with the new request for App B?

Thanks.

Answer 1

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