Managing multiple passwords can be overwhelming, pushing users towards insecure practices due to the difficulty of remembering strong and unique passwords.
Users might resort to placing passwords on sticky notes or storing them in insecure files or setting them all the same, posing significant security risks.
The difficulty of remembering passwords for different systems prompts the search for a more secure and manageable solution.
Q1. What is SSO?
Single Sign-On (SSO) is an authentication scheme that allows a user to access multiple applications and services with a single set of credentials, eliminating the need to log in separately for each application. It enhances user convenience and security by centrally managing and authenticating users across various systems.
Users log in once to an SSO manager, a specialized tool or software, using a complex password. The SSO manager then recalls the unique passwords for all connected systems.
Q2. How does SSO work?
There are two common protocols for the authentication process: SAML and OpenID Connect.
Let’s delve into a standard Single Sign-On (SSO) login flow using SAML.
① Authentication Request
The SSO login flow begins as a user accesses a Service Provider (ex. Gmail, Slack, or Workday). The Service Provider detects the user’s domain and initiates the process by sending a SAML Authentication Request (SAR) to the user’s browser.
② Redirect to Identity Provider (IdP)
The user’s browser is then redirected to the specified Identity Provider (ex. Okta, Auth0, or OneLogin) as indicated in the SAML authentication request. The Identity Provider presents a login page, prompting the user to enter their credentials.
③ User Authentication
Upon entering credentials, the Identity Provider authenticates the user. Following successful authentication, the Identity Provider generates a SAML response, commonly known as a SAML assertion. This cryptographically-signed XML document contains user information and access privileges.
④ Forwarding SAML Assertion
The user’s browser forwards the signed SAML assertion back to the original Service Provider.
⑤ Assertion Validation
The Service Provider validates the received SAML assertion, typically using public key cryptography to ensure the document was signed by the trusted Identity Provider.
⑥ Access Granted
Upon successful validation, the Service Provider grants access to the protected resource, adhering to the permissions specified in the SAML assertion. This process ensures a seamless user experience with access to applications without the need for repeated logins.
Let’s look at what happens when the user switches to another SSO-enabled application, like Workday.
Workday, similar to the Gmail example, detects the work domain, sends a SAML authentication request to the browser, and redirects the user to the Identity Provider. Since the user is already authenticated, the login step is skipped. Instead, a SAML assertion is generated for Workday, specifying the user’s access details. The browser sends this assertion to Workday, which validates it and grants the user access.
Security Measures and Benefits of SSO
While some worry about a single point of failure with SSO, it actually makes things more secure. With SSO, unique passwords are assigned to each system, mitigating the risk of a domino effect if one system is hacked. The approach minimizes the extent of damage to a single system, providing a more secure environment.
To further enhance security, SSO can be augmented with multi-factor authentication (MFA), adding an extra layer of verification on top of a password. This combination of SSO and MFA makes the overall security stronger, offering a streamlined yet robust authentication process for users accessing various applications and resources.
Q3. SAML or OpenID Connect for Single Sign-On?
Deciding between SAML (Security Assertion Markup Language) and OpenID Connect depends on different things, like what a specific application needs, how easy it is to put them together, and what the identity management system can do. Both SAML and OpenID Connect are secure, widely used in big businesses, and supported by many identity providers.
SAML: Secure Federation for Web Apps
SAML serves as a robust protocol. It lets Identity Providers (IDPs) securely federate identity for authentication and authorization into web apps. Even though it’s good at managing who can do what with XML schemas, it can be tough for Service Providers (SPS) to set up and might cost extra. SAML is often used for websites, making sure passwords are sent and stored safely using XML documents to share info about the user.
OpenID Connect: Lightweight Authentication for Applications
OpenID Connect is known for being simple, making it easy for Service Providers (SPS) to use. It’s great for managing sign-ins and assertions in mobile apps because it’s light and works fast. Unlike SAML, it sends users from one place to another for authentication. Calls go straight between the user (the Relying Party) and where they need to be (the OpenID Provider), using REST and JSON messages that are easy to get with APIs.
Choosing Between SAML and OpenID Connect
Picking between SAML and OpenID Connect comes down to a few things, including technical requirements, organizational applications, and available resources for Single Sign-On (SSO) implementation. Both protocols serve effectively as authentication methods, and organizations may benefit from using them together with other standards depending on what they need. The choice should match up with what a business wants and needs in their identity management plan.