SSO

Single Sign-On (SSO) is a solution which lets users authenticate at one application and then use that same user session at many completely different applications without re-authenticating over and over again.

HTTP Cookies (RFC 6265) are vital component to achieve SSO, as it tracks the user’s session across different applications. Before going in detail on SSO, let’s look at the HTTP Cookies.

HTTP Cookies

• An HTTP cookie is a name-value pair data sent by a web-server (party-1) to a web-browser (party-2) to maintain a state between those two parties.
• Because of state maintenance mechanism, cookies are used for,
  • Tracking user’s information and browsing patterns: For example: preserving cart items in a shopping website and displaying advertisements based on browsing history .
  • User authentication: To know whether the user is logged in or not, and which account they are logged in with.
• HTTP Cookies (RFC 6265) has defined some attributes associated with cookies: They are:

Attributes	Explanations
Name/ Value	Any US-ASCII characters with some exceptions. For example: SessionID=123
Domain	– If specified, the domain and subdomains of the cookie where this cookie can be sent to. For eg: if Domain=example.com; then browser can send cookie to example.com and host1.example.com as well) – If not specified, domain will be derived from the request-domain (actual hostname from URL) and browser only send to the exact domain and not to its subdomains. For eg: from earlier case, the browser can send only to host that which it set the cookie, i.e., to host1.example.com only.
Path	A given URL path where the cookie applies to. For eg: / (i.e., root path)
Expires	GMT timestamp that says when the cookie expire. For eg: 2018-08-24T22:30:17.000Z. If not specified, the cookie is valid until the browser closed.
Max-Age	The amount of time (in seconds) the cookie should be valid. For eg: 3600. Both Expires and Max-Age are used for session timeout and context remains same. If both (Expires and Max-Age) are set, Max-Age will have precedence.
Secure	When used, the cookie can be only transferred through HTTPS, regular HTTP requests won’t include this cookie.
HttpOnly	When used, the cookies aren’t accessible via JavaScript, giving some protection against cross-site scripting (XSS) attacks.
SameSite	Prevents the browser from sending the cookie along with cross-site requests. Provides some protection against cross-site request forgery (CSRF) attacks. Possible values are: – Strict: Cookie won’t be sent to target site in all cross-domain browsing context. – Lax: Cookie will be sent along with the GET request initiated by the third-party website, but not request to POST or request originated from iframe, img, and script tags. CSRF attacks are only possible since Cookies are always sent with any requests that are sent to a particular origin, which is related to that Cookie. Due to the nature of a CSRF attack, a flag can be set against a Cookie, tuning it into a same-site Cookie. A same-site Cookie is a Cookie which can only be sent, if the request is being made from the same origin that is related to the Cookie being sent. The Cookie and the page from where the request is being made, are considered to have the same origin if the protocol, port (if applicable) and host is the same for both.

• Creating a cookie with same name (value can be anything), and set the Expires property to a date in the past will make that cookie to be removed or cleared-out from the browser and user will lose his/ her session.

How Cookies are related to SSO?

Cookies are the ones controls and tracks the user session in the web-browser and that helps to achieve the SSO across all applications within the same domain. Refer below sequence diagram and its explanations in detail.

SSO Sequence Diagram

Note: All servers are hosted in the same domain example.com.

1. User request page1.html from host1.example.com (Application-1 & Web Agent-1).
2. host1.example.com sees there is no valid Session Cookie.
3. Hence redirect the user to sso.example.com (SSO & Authentication Services) for authentication with return URL as page1.html.
4. Browser request for authentication to Authentication service.
5. Authentication service displays login page for the user to enter their username/ password.
6. User submits username/ password.
7. Authentication service authenticates the submitted credentials.
8. Upon successful authentication, Authentication service sets redirect URL to page1.html (from #3) and SSO service sets the Session Cookie with the following attributes:
   

   Cookie Attributes	Values	Explanations
   Name/ Value	SessionID=123	This Session Cookie is named as SessionID and value as 123.
   Domain	example.com	This Session Cookie is valid for domain example.com and all its subdomains like sso.example.com, host1.example.com and host2.example.com.
   Path	/	This Session Cookie applies to path root.
   Expires/ Max-Age	2018-08-24T22:30:17.000Z	This Session Cookie will expire on July 24, 2018 at 10:30PM, GMT.
   HttpOnly	HttpOnly	This Session Cookie is not accessible from   JavaScripts.
   Secure	Secure	This Session Cookie can be sent only in HTTPS connections.
   SameSite	Strict	This Session Cookie is not valid for any cross-domain browsing context.

9. Browser redirect to page1.html at host1.example.com with the Session Cookie.
10. host1.example.com asks SSO service to validate the received Session Cookie.
11. SSO service validates and return response to host1.example.com.
12. Finally host1.example.com allows user to access page1.html.
13. After sometime, in the same browser session, the same user with valid Session Cookie request to access page2.html at host2.example.com (Application-2 & Web Agent-2).
14. host2.example.com request SSO service to validate the received Session Cookie.
15. SSO service validates and return response to host2.example.com.
16. Finally host2.example.com allows user to access page2.html without asking to re-login at sso.example.com.
    • This is because the Session Cookie is bound and valid to domain example.com, and hence SSO & Authentication Services did not authenticate the user once again.

Conclusion

• So far we saw SSO works fine across applications when their domain name is same (i.e., sso.example.com, host1.example.com and host2.example.com, all are based on same domain example.com).
• But what happen if applications running on different domains? For example: sso.example.com, host1.example1.com, host2.example2.com. How to achieve SSO for these applications?
  • The answer is Cross Domain-Single Sign-On (CD-SSO).
• Let’s discuss about CD-SSO in next blog post. At least this blog gives some basic concepts on SSO and let’s look in the next post for complex use-cases on CD-SSO.