Single Sign-On (SSO)

The Identity Provider (IdP) is the central, trusted service that performs authentication and issues assertions about a user's identity. It is the 'source of truth' for user credentials and session state.

• Primary Role: Authenticates users, manages sessions, and generates security tokens (like SAML assertions or JWTs).
• Key Protocols: Supports standards like SAML 2.0, OpenID Connect (OIDC), and WS-Federation.
• Examples: Okta, Microsoft Entra ID (Azure AD), Ping Identity, Auth0, Keycloak.

The Service Provider (SP) or Relying Party (RP) is the application or service the user wants to access. It trusts the Identity Provider to authenticate users and delegates that responsibility.

• Primary Role: Consumes authentication assertions from the IdP, grants application access, and enforces local permissions.
• Trust Relationship: Must be pre-configured with the IdP's metadata (e.g., public signing certificates, endpoints).
• Process: Redirects unauthenticated users to the IdP and validates the returned security token.

Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between an IdP and a Service Provider. It is a core protocol for many enterprise SSO implementations.

• Assertions: Carry statements about a user's authentication, attributes, and authorization decisions.
• Flow: Uses browser POST or redirect bindings to exchange messages.
• Use Case: Common in B2B and enterprise applications where the SP and IdP are in different security domains.

OpenID Connect (OIDC) is a modern, JSON-based identity layer built on OAuth 2.0. It provides authentication (verifying who the user is) using the OAuth 2.0 authorization framework.

• ID Token: A JSON Web Token (JWT) that contains verifiable claims about the user's identity.
• UserInfo Endpoint: A standardized API to retrieve additional user attributes.
• Advantage: Simpler and more API-friendly than SAML, making it ideal for modern web and mobile applications.

Session Management is the mechanism by which the IdP maintains a user's authenticated state across multiple Service Providers. Single Logout (SLO) terminates all sessions across all participating applications simultaneously.

• Central Session: The IdP maintains a primary session; SP sessions are derivatives.
• SLO Protocols: Both SAML and OIDC define standards for logout propagation.
• Challenge: Requires all SPs to support the logout protocol and be reachable at logout time, which can be complex in distributed environments.

The User Attribute Store is the directory or database (like LDAP, Active Directory, or a SQL database) where the IdP retrieves user profile information (e.g., email, groups, roles).

• Just-In-Time (JIT) Provisioning: A process where a user account is automatically created in the SP's local user directory upon first successful SSO login, using attributes from the IdP's assertion.
• Benefits: Eliminates manual user account management at the SP and enables seamless access for new users.

The system component that intercepts access requests and enforces authorization decisions. In a zero-trust API gateway context, the gateway itself acts as the PEP. It validates SSO-issued tokens, checks policies, and permits or denies API traffic before it reaches backend services.

• Location: Typically implemented as an API Gateway or a reverse proxy.
• Action: Grants or denies access based on decisions from a Policy Decision Point (PDP).
• SSO Integration: Intercepts requests, extracts the SSO token (e.g., JWT), and validates its signature and claims.

An advanced access control model where authorization decisions are dynamically made using a rich set of signals beyond simple user identity. After SSO authentication, this system evaluates contextual attributes like device security posture, geolocation, time of access, and behavioral patterns to make a granular permit/deny decision.

• Beyond Roles: Extends Role-Based Access Control (RBAC) with real-time signals.
• Dynamic Policies: Enables rules such as "Access from corporate device only" or "Block logins outside business hours."
• SSO Synergy: Uses identity established by SSO as the primary attribute, enriched by other context for a final decision.

A compact, URL-safe token format (RFC 7519) used to securely transmit claims between parties. In SSO flows, the identity provider often issues a signed JWT as an ID Token or Access Token. The API gateway validates the JWT's signature and examines its claims (like sub for subject, exp for expiry) to make access decisions.

• Structure: Header.Payload.Signature, with the payload containing JSON claims.
• Self-Contained: Carries all necessary information, reducing need for database lookups.
• Critical for Zero-Trust: Enables stateless, scalable verification of user identity and permissions at the PEP.

An authentication protocol where both the client and server present and validate each other's X.509 digital certificates. In a zero-trust architecture, mTLS is used for machine-to-machine authentication, often complementing user-focused SSO. An API gateway can use mTLS to verify the identity of a service or autonomous agent before it even presents an SSO user token.

• Strong Machine Identity: Provides cryptographic verification of client software (e.g., an AI agent).
• Layered Security: Establishes a secure channel (TLS) where user credentials (SSO tokens) are then exchanged.
• Use Case: Authenticating backend services, IoT devices, or autonomous systems calling APIs.