How Single Sign on works in application suite within organization?

Single sign on is the technology where user can access multiple applications of the same organization by logging into any one of them. The beauty of this process is that it is not required for these applications to be hosted on same domain or server or have any kind of similarity with each other. We are going to understand the architecture and implementation process of SSO.

Introduction

For large organizations, it is very difficult to manage user credentials. Since these organizations work on multiple applications so separate login system is required for all. To deal with this problem, single sign on is introduced. Sign in once and access the complete suite.

Important Terms

1. IAM – Identity & Access Management. This is the system which manages the resource access of cloud services. IAM is responsible to allow or refuse access of a service or resource to a user of an organization. Single Sign on is one of the service of IAM.
2. SSO – Single Sign On
3. IDP – Identity Provider. Idp is the third party which acts as an authenticator between client (browser) and server (website). Google, AWS, Azure AD are some of the trusted IDPs.
4. Token – An encrypted hash of authentication & identity information created by IDP. These hashes are extremely hard to decrypt or read for a hacker. That’s why they can be securely transferred from browsers to servers.
5. Key – A key is the piece of string which can decrypt a token and reveal the useful information. They are securely stored on the servers.
6. SAML – Security Assertion Markup Language. This is an SSO protocol which uses XML based scheme.
7. OIDC – OpenID Connect – Another SSO protocol which uses JSON based scheme.
8. Federation – When you use multiple IDPs for SSO, then a chain of authentication is created which is known as federation.

Architecture Background

Let’s see how single sign on works?

First of all there are two types of SSO (single sign on) –

1. Where you trust a service and use that for signing in to all the applications which are using that service. For example Google Sign In, Facebook Login, LinkedIn sign in etc. Here you use your Google, Facebook and LinkedIn accounts to access other applications. But you will need to authenticate all the applications separately.
2. In second type, you login into one application and get automatically logged in into all the other applications of one organization. This scheme works on a suite. Like, when you log into gmail, you get logged in into adwords, adsense, analytics, console and all the other suite applications automatically. No separate authentication is required here.

SSO authentication, step by step

In this section we will answer the questions like –

• how browser sends authentication data to server?
• How server authenticates without credentials?
• What is the role of IDP?
• How keys and tokens works?
• How server knows its time to re-login? etc.

Step 1: Browser sends request to Server

When you wish to access some website, you don’t care about opening the login page. You simply hit the page you are interested in. Now server checks whether you are logged in or not and accordingly redirects you to either at your page of interest or login form.

In SSO there is no login form of the website. Else it is using IDP for its authentication. So, server will ask the user to get authenticated with IDP.

Step 2: Server asks verification token from IDP

If user is not logged in or server do not find session cookie, then it sends a request to IDP for verification token. This takes place through the browser. There are few directions from here –

1. If server knows that user has logged into its application in the past, then it can create a url which will redirect the browser to the IDP login screen (If user is not logged in to IDP or her session is expired). If she is signed in already, then it will skip the screen and fetch the token directly and send it back to the server.
   

   

2. If the user is accessing the website for the first time then she will need to authenticate it with IDP. So, server will create a link to redirect user to a page where she can select appropriate IDP from the list (There could be multiple like Login with Google, Login with Facebook etc.). After choosing one, it will ask user if they wish to grant access of their personal information to that particular website. Then the process will be same as point 1.
   

   

Step 3: Server checks validity of token and fetch user data

The verification token received by server is an encrypted piece of string which can be decrypted only if IDP allows. In other case the server needs to fetch user data like email, name, user id from IDP directly. This happens by sending the verification token to IDP to validate whether its expired or tempered. If everything is all right, then IDP sends back user information.

Step 4: Server logged user in and returned requested page to the browser

Server got user information like name, email, id etc. It has verified the token from IDP directly and hence logged user into its system. It will now send the requested page to the browser and set the session cookie.

Summary in a nutshell

1. Servers (Websites) registers themselves to all the IDPs they want to support. IDPs asks them about what personal information of a user, they want to access and provides them the private keys for decoding the client tokens and to prove their identity.
2. Browser requests a page (A) along with website session cookie.
3. Server checks if session cookie is valid, non-expired and user is already logged in.
   1. If logged in then the requested page is returned.
   2. If not, then proceed with point 4.
4. Server checks if user is logging first time on the website or returning one.
   1. If first time logging in, then proceed with point 5.
   2. If returning one, then proceed with point 6.
5. Server will redirect the user to a page where multiple IDPs are listed like Google, Facebook, LinkedIn etc. User will select the IDP with which she wish to log in and will be redirected to that IDP. Proceed to point 7.
6. Server knows the IDP with which user logged into website in the past. So, it will create a link to redirect user to that IDP.
7. The redirection is through browser so IDP will get its own session cookie which was stored on user’s browser.
8. IDP will check (from its session cookie) if the user is logged in or session expired.
   1. If session expired, then proceed with point 9.
   2. If already logged in, then proceed with point 10.
9. IDP will show a login form to user with id/email and password fields. Once the user submits the form, it will set its session cookie on her browser.
10. If user is first time logging in to the website then she will be asked her consent to grant access of personal information to that website. IDP now generates the verification token and returns that to the browser.
11. Browser sends the token to the server.
12. Server now needs to verify if the token is valid. So it sends the token and the key to the IDP (directly, not through browser) where IDP verifies its authenticity and returns back the response. This response will contain the status (error or success) and user information like name, email, id etc. whatever user permitted and IDP allowed server to receive.
13. Server logs user in, create session cookie and return the page (A) requested by browser in point 2.

Frequently Asked Questions

Q2. Why single sign on is required?

Answer: Due to increase in number of web based products, it became hard for users to remember different username/password combinations. To solve this issue, a single sign on scheme was introduced where one credential at one site (IDP) could be used for multiple websites without compromising any security.

Q3. Can any website access my information?

Answer: No. When a user try to login first time to a website, IDPs take the consent of the user if they want to share their information and what information the website needs and what you want to share, out of them. After granting the access, website will be liable to get the information.

Q4. Why server creates the link which passes to IDP through browser?

Answer: The one who needs to be logged in is user. And user can access browser. The link passes through browser because it needs to carry the IDP session cookie.

Q5. Why IDP session cookie is required?

Answer: IDP itself need to check if user is logged into its system. Otherwise it will have to ask her to enter credentials, every time she tries to access a website. To prevent this, session cookies are created and stored on browsers.

Q6. Can this session cookie be tampered?

Answer: Technically, yes. But, these cookies can only be read by the websites which set them. Also, they are transferred over secured SSL connection. They could be tempered but not so easily be misinformed. If tempered then websites find them corrupted and discard them.

Q7. Why verification token is sent by IDP and through browser?

Answer: Verification token signifies the login status of users. Since websites asked for token through browsers, so the response is also passed through browsers only. Also, sometimes a copy of token is stored there in cookies.

Q8. What information does verification token have?

Answer: It holds information like user data, creation & expiry date, website identification data etc.

Q9. Can a token generated for one website be used by another website?

Answer: No. All the tokens are generated by using website identification data only. They can only be transferred to the websites they are designed for. If, by any means, any undesirable website access the token, then also it will be a useless piece of string for that because they won’t be able to decode it with their private key.

Q10. Verification token passes through browser, isn’t it insecure?

Answer: No. First of all it passes through a secured link. Second, the cookies can only be accessed by websites which sets them. Third, the token is the encrypted form of useful information which is highly secured by industry best crypto algorithms. It’s very very hard to break them.

Q11. Why server checks the validity of token?

Answer: To keep anything safe on internet, we need to periodically replace them with fresh data. Outdated and frequently used data are more susceptible to hack. So, there is always an expiration date attached to the tokens.

Server, after receiving the token, needs to verify –

1. If token was meant to website?
2. If it is new and not expired?
3. Is it tempered in any way?
4. Is the user impersonating as someone else?

This verification is easy by sending the token and private key to the IDP. It checks if the token was correct and meant for the website with that private key. This communication is done from server directly and there is no role of browser. So, the response by IDP is trustful.

Conclusion

This is all about single sign on. We learned the architecture and workings. And we answered few commonly asked questions.

References & Research

Computing & Communication Services, University of Guelph

Using SSO with system failover

OpenID connect authorization, MIT

Microsoft Azure Active Directory Documentation

Google Workspace Admin