Single Sign On (SSO) makes it simple for users to begin using an application. Support for SSO is crucial for enterprise apps, as many corporate security policies mandate that all applications use certified SSO mechanisms. While the SSO experience is straightforward, the SSO standard is anything but straightforward. It's easy to get confused when you're surrounded by complex jargon, including SAML, OAuth 1.0, 1.0a, 2.0, OpenID, OpenID Connect, JWT, and tokens like refresh tokens, access tokens, bearer tokens, and authorization tokens. Standards documentation is too precise to allow generalization, and vendor literature can make you believe it's too difficult to do it yourself.

I've created SSO for a lot of applications in the past. Knowing your target market, norms, and platform are all crucial.

Single Sign On

Single Sign On is an authentication method that allows apps to securely authenticate users into numerous applications by using just one set of login credentials.

This allows applications to avoid the hassle of storing and managing user information like passwords and also cuts down on troubleshooting login-related issues. With SSO configured, applications check with the SSO provider (Okta, Google, Salesforce, Microsoft) if the user's identity can be verified.

Types of SSO

• Security Access Markup Language (SAML)
• OpenID Connect (OIDC)
• OAuth (specifically OAuth 2.0 nowadays)
• Federated Identity Management (FIM)

Security Assertion Markup Language - SAML

SAML (Security Assertion Markup Language) is an open standard that enables identity providers (IdP) to send authorization credentials to service providers (SP). Meaning you can use one set of credentials to log in to many different websites. It's considerably easier to manage a single login per user than to handle several logins to email, CRM software, Active Directory, and other systems.

For standardized interactions between the identity provider and service providers, SAML transactions employ Extensible Markup Language (XML). SAML is the link between a user's identity authentication and authorization to use a service.

In our example implementation, we will be using SAML 2.0 as the standard for the authentication flow.

Technical details

• A Service Provider (SP) is the entity that provides the service, which is in the form of an application. Examples: Active Directory, Okta Inbuilt IdP, Salesforce IdP, Google Suite.
• An Identity Provider (IdP) is the entity that provides identities, including the ability to authenticate a user. The user profile is normally stored in the Identity Provider typically and also includes additional information about the user such as first name, last name, job code, phone number, address, and so on. Depending on the application, some service providers might require a very simple profile (username, email), while others may need a richer set of user data (department, job code, address, location, and so on). Examples: Google - GDrive, Meet, Gmail.
• The SAML sign-in flow initiated by the Identity Provider is referred to as an Identity Provider Initiated (IdP-initiated) sign-in. In this flow, the Identity Provider begins a SAML response that is routed to the Service Provider to assert the user's identity, rather than the SAML flow being triggered by redirection from the Service Provider. When a Service Provider initiates the SAML sign-in process, it is referred to as an SP-initiated sign-in. When end-users try to access a protected resource, such as when the browser tries to load a page from a protected network share, this is often triggered.

Configuration details

• Certificate - To validate the signature, the SP must receive the IdP's public certificate. On the SP side, the certificate is kept and used anytime a SAML response is received.
• Assertion Consumer Service (ACS) Endpoint - The SP sign-in URL is sometimes referred to simply as the URL. This is the endpoint supplied by the SP for posting SAML responses. This information must be sent by the SP to the IdP.
• IdP Sign-in URL - This is the endpoint where SAML requests are posted on the IdP side. This information must be obtained by the SP from the IdP.

OpenID Connect - OIDC

OIDC protocol is based on the OAuth 2.0 framework. OIDC authenticates the identity of a specific user, while OAuth 2.0 allows two applications to trust each other and exchange data.

So, while the main flow appears to be the same, the labels are different.

How are SAML and OIDC similar?

The basic login flow for both is the same.

1. A user tries to log into the application directly.

2. The program sends the user's login request to the IdP via the browser.

3. The user logs in to the IdP or confirms that they are already logged in.

4. The IdP verifies that the user has permission to use the program that initiated the request.

5. Information about the user is sent from the IdP to the user's browser.

6. Their data is subsequently forwarded to the application.

7. The application verifies that they have permission to use the resources.

8. The user has been granted access to the program.

Difference between SAML and OIDC

1. SAML transmits user data in XML, while OpenID Connect transmits data in JSON.

2. SAML calls the data it sends an assertion. OAuth2 calls the data it sends a claim.

3. In SAML, the application or system the user is trying to get into is referred to as the Service Provider. In OIDC, it's called the Relying Party.

SAML vs. OIDC

1. OpenID Connect is becoming increasingly popular. Because it interacts with RESTful API endpoints, it is easier to build than SAML and is easily available through APIs. This also implies that it is considerably more compatible with mobile apps.

2. You won't often have a choice between SAML and OIDC when configuring Single Sign On (SSO) for an application through an identity provider like OneLogin. If you do have a choice, it is important to understand not only the differences between the two, but also which one is more likely to be sustained over time. OIDC appears to be the clear winner at this time because developers find it much easier to work with as it is more versatile.

Use Cases

1. SAML with OIDC:

- Log in with Salesforce: SAML Authentication where Salesforce was used as IdP and the web application as an SP.

Key Reason:

All users are centrally managed in Salesforce, so SAML was the preferred choice for authentication.

- Log in with Okta: OIDC Authentication where Okta used IdP and the web application as an SP.

Key Reason:

Okta Active Directory (AD) is already used for user provisioning and de-provisioning of all internal users and employees. Okta AD enables them to integrate Okta with any on-premise AD.

In both the implementation user provisioning and de-provisioning takes place at the IdP side.

SP-initiated (From web application)

IdP-initiated (From Okta Active Directory)

‍

2. Only OIDC login flow:

• OIDC Authentication where Google, Salesforce, Office365, and Okta are used as IdP and the web application as SP.

‍

Why not use OAuth for SSO

1. OAuth 2.0 is not a protocol for authentication. It explicitly states this in its documentation.

2. With authentication, you're basically attempting to figure out who the user is when they authenticated, and how they authenticated. These inquiries are usually answered with SAML assertions rather than access tokens and permission grants.

OIDC vs. OAuth 2.0

• OAuth 2.0 is a framework that allows a user of a service to grant third-party application access to the service's data without revealing the user's credentials (ID and password).
• OpenID Connect is a framework on top of OAuth 2.0 where a third-party application can obtain a user's identity information which is managed by a service. OpenID Connect can be used for SSO.
• In OAuth flow, Authorization Server gives back Access Token only. In the OpenID flow, the Authorization server returns Access Code and ID Token. A JSON Web Token, or JWT, is a specially formatted string of characters that serves as an ID Token. The Client can extract information from the JWT, such as your ID, name, when you logged in, the expiration of the ID Token, and if the JWT has been tampered with.

Federated Identity Management (FIM)

Identity Federation, also known as federated identity management, is a system that allows users from different companies to utilize the same verification method for access to apps and other resources.

In short, it’s what allows you to sign in to Spotify with your Facebook account.

• Single Sign On (SSO) is a subset of the identity federation.
• SSO generally enables users to use a single set of credentials to access multiple systems within a single organization, while FIM enables users to access systems across different organizations.

‍

How does FIM work?

• To log in to their home network, users use the security domain to authenticate.
• Users attempt to connect to a distant application that employs identity federation after authenticating to their home domain.
• Instead of the remote application authenticating the user itself, the user is prompted to authenticate from their home authentication server.
• The user's home authentication server authorizes the user to the remote application and the user is permitted to access the app. The user's home client is authenticated to the remote application, and the user is permitted access to the application.

A user can log in to their home domain once, to their home domain; remote apps in other domains can then grant access to the user without an additional login process.

‍Applications:

• Auth0: Auth0 uses OpenID Connect and OAuth 2.0 to authenticate users and get their permission to access protected resources. Auth0 allows developers to design and deploy applications and APIs that easily handle authentication and authorization issues such as the OIDC/OAuth 2.0 protocol with ease.
• AWS Cognito
• User pools - In Amazon Cognito, a user pool is a user directory. Your users can sign in to your online or mobile app using Amazon Cognito or federate through a third-party identity provider using a user pool (IdP). All members of the user pool have a directory profile that you may access using an SDK, whether they sign indirectly or through a third party.
• Identity pools - An identity pool allows your users to get temporary AWS credentials for services like Amazon S3 and DynamoDB.

Conclusion:

I hope you found the summary of my SSO research beneficial. The optimum implementation approach is determined by your unique situation, technological architecture, and business requirements.