How SSO (Single Sign On) Works

Question

I am trying to wrap my head around SSO. I understand that SSO allows you to log in once and access multiple applications (if you have rights). So, I enter application A. I am installing a token. How does this token become available for application B, so I do not need to log in to application B again (if the user has rights to A and B)? My applications are AngularJs applications. I am accessing .Net WebAPis for data.

I can find out if I went into application A and extracted the token, and then launched application B from application A, transferring the token to application B. Thus, application B has a token and can send to the server to make sure that the user has access to B However, if the user opens the browser directly and goes to application B, then how is their session established with the existing token?

If the answer is session state on the internal server, then how does the session state correspond to the user registered in application A with a new request for application B?

Thanks.

Answer 1

Well, of course, there are many ways to achieve this, and it can be difficult. I can give you one solution as an example:

Consider two applications on different subdomains:

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

These two web applications want to share a signature and organize a third hosted website for their single sign-on:

 sso.example.com 

Then the stream:

• Frank visits http://turkey.example.com/orders/12
• Turkey redirects to https://sso.example.com/login
• SSO represents the user with the login form, checks and eliminates the token
• The token is stored in a cookie on the SSO.
• The user is now checked for SSO, but he needs to return the token to the turkey.
• SSO stores the combination (Guid, Token, Expiry) on the server, where Guid is a random landmark and Expiry is about 30 seconds.
• SSO sets a secure cookie on * .example.com containing Guid
• SSO redirects back to http://turkey.example.com/orders/12
• Turkey can now get a ticket from cookie
• Turkey calls the SSO server and exchanges a ticket for a token.
• Turkey stores the token in the browser (usually a cookie)

Now imagine that Frank wants nice juicy baboons with this turkey:

• Frank visits: http://monkey.example.com/order-in-bulk
• The monkey sees that Frank does not have a saved token and is redirected to https://sso.example.com/login
• SSO sees that Frank is already registered, as he has a saved token.
• SSO saves a new (Guid, token, expiration) triple on the server
• The process is identical to the initial login.

Answer 2

However, if the user opens the browser directly and goes to application B, then how is their session established with the existing token?

If the response has a session state on the internal server, then how does the session state correspond to the user registered in application A with a new request for application B?

I would say that this is more about cookies and redirects than tokens. Tokens are generated after the identification of the user.

So, when you get to application B through a browser, application B redirects your user agent to the Auth server (which can, in turn, redirect you to the SSO site).

It should be noted that the SSO login request is an HTTP request between your browser and the SSO server.

So, the SSO cookie already exists, because earlier the application A also redirected your user agent to the Auth / SSO server where the login was made. After that, the SSO server can save a cookie between you and him.

I can see if I can log into application A and get a token, and then run application B from application A, passing the token to application B.

I'm not sure that I understand that application A transfers its token to application B. Typically, applications (Oauth 2.0 clients) will not share tokens. Appendix B should make its own request to the Auth server, which (if the user is registered) can skip the login part, but then must confirm that:

• Appendix B has rights to the requested areas and

• a subscribed user has granted access to these areas.

If the user is logged in and has previously approved access to the access area, all this processing will be fully accessible to the end user, except for the forwarding pool.

Assuming you are using a stream of implicit grants (I noticed that one of your applications is a corner application).

If you use Oauth2.0 grants for code, password, or client, then you can get the update token after the initial login and user consent.

The update current corresponds to long-term access (only for this application) without the need to re-enter the system and obtain consent from the end user more than once.