In today’s interconnected digital landscape, Single Sign-On (SSO) plays a crucial role in streamlining authentication and access management. SSO enables users to log in once and gain access to multiple applications without needing to authenticate separately for each service. This is achieved through standardized authentication and authorization protocols such as SAML, OIDC, OAuth2.0, SCIM, and WS-Federation. In this blog, we will explore these protocols, how they work, and how they can be implemented using Entra ID (formerly Azure AD) and Okta.

1. Security Assertion Markup Language (SAML)

SAML is an XML-based authentication protocol used primarily for web applications. It allows an Identity Provider (IdP) to authenticate users and pass their identity information to Service Providers (SPs) via SAML assertions.

How SAML Works:

  1. The user attempts to access a Service Provider (SP).
  2. The SP redirects the user to the Identity Provider (IdP) for authentication.
  3. The IdP authenticates the user and sends a SAML assertion back to the SP.
  4. The SP validates the assertion and grants access.

Example:

A company uses Google Workspace as an Identity Provider (IdP) and integrates it with Salesforce as a Service Provider (SP) via SAML-based SSO. Users log in once through Google and gain access to Salesforce without entering credentials again.

Implementation in Entra ID & Okta:

  • Entra ID: Configure Enterprise Applications and enable SAML-based SSO.
  • Okta: Use SAML App Integration to set up identity federation with applications.

2. OpenID Connect (OIDC)

OIDC is an identity layer built on OAuth 2.0, allowing authentication through JSON Web Tokens (JWTs).

How OIDC Works:

  1. A user logs into an application (Relying Party).
  2. The application redirects the user to an OIDC Identity Provider (IdP) (e.g., Google, Microsoft Entra ID).
  3. The IdP authenticates the user and returns an ID Token.
  4. The application validates the ID Token and grants access.

Example:

A mobile banking app uses Google as an IdP via OIDC. Users authenticate using their Google credentials instead of creating a separate account.

Implementation in Entra ID & Okta:

  • Entra ID: Enable OIDC authentication for cloud applications.
  • Okta: Configure an OIDC app in the Okta developer console.

3. OAuth 2.0

OAuth 2.0 is an authorization framework that allows third-party applications to access resources without exposing user credentials.

How OAuth 2.0 Works:

  1. A user logs into an application and requests access to a third-party API.
  2. The application redirects the user to an OAuth Authorization Server.
  3. The user consents, and the Authorization Server issues an Access Token.
  4. The application uses the Access Token to access the resource.

Example:

A travel website requests permission to access a user’s Google Calendar via OAuth 2.0 to book flights automatically.

Implementation in Entra ID & Okta:

  • Entra ID: Set up OAuth 2.0 authorization endpoints for API access.
  • Okta: Use OAuth API authorization servers to manage API access.

4. System for Cross-domain Identity Management (SCIM)

SCIM is a protocol for managing user identities across different systems.

How SCIM Works:

  1. A user account is created in an Identity Provider (IdP).
  2. The IdP automatically provisions the account in external applications.
  3. When the user is deactivated, SCIM ensures deprovisioning across all applications.

Example:

A company using Okta provisions users in Slack automatically using SCIM.

Implementation in Entra ID & Okta:

  • Entra ID: Enable SCIM provisioning in Enterprise Applications.
  • Okta: Use SCIM integration for automated user provisioning.

5. WS-Federation

WS-Federation is an authentication protocol that enables federated identity between identity providers and service providers using SAML-like tokens.

How WS-Federation Works:

  1. A user requests access to a web application.
  2. The application redirects the user to a WS-Federation Security Token Service (STS).
  3. The STS issues a security token containing the user’s identity information.
  4. The application validates the token and grants access.

Example:

An enterprise integrates on-premises Active Directory Federation Services (ADFS) with Microsoft 365 using WS-Federation for seamless authentication.

Implementation in Entra ID & Okta:

  • Entra ID: Configure WS-Federation trust relationships.
  • Okta: Enable WS-Federation connections for legacy applications.

Conclusion

Each SSO protocol serves a unique purpose in authentication and authorization. By leveraging SAML, OIDC, OAuth 2.0, SCIM, and WS-Federation, organizations can enhance security, streamline user access, and simplify identity management. Whether using Entra ID or Okta, implementing these protocols correctly ensures seamless and secure authentication across applications.

Would you like a step-by-step implementation guide for any specific protocol? Let us know!