Identity Provider (IdP)

The User Identity Store is the authoritative database or directory (e.g., LDAP, Active Directory, SQL database) that persists core user attributes and credentials. It is the source of truth for identity data, storing:

• Username and unique identifiers
• Hashed passwords or other credential secrets
• User attributes (email, department, group membership)
• Account status (active, locked, disabled)

For AI agents, this store defines the set of human and service principals that can be authenticated.

The Authentication Engine is the core logic that validates credentials presented by a user or service. It performs the verification step, supporting multiple authentication factors:

• Knowledge Factors: Passwords, PINs (Something you know)
• Possession Factors: Time-based One-Time Passwords (TOTP), hardware tokens, push notifications (Something you have)
• Inherence Factors: Biometrics like fingerprints or facial recognition (Something you are)

For AI agent tool-calling, this engine validates the agent's own service account or the delegated user identity before allowing API execution.

The Token Service generates and validates security tokens after successful authentication. These standardized, cryptographically signed tokens convey verified claims about the identity. Common formats include:

• Security Assertion Markup Language (SAML) assertions
• JSON Web Tokens (JWT) used in OAuth 2.0 and OpenID Connect

Tokens enable stateless session management and are critical for AI agents, as they are the portable credential presented to Policy Enforcement Points (PEPs) at external APIs to prove authentication and authorization.

Within an IdP, the Policy Decision Point (PDP) evaluates context and rules to make authorization decisions about what an authenticated identity is allowed to do. It answers "Is this user/agent allowed to perform action X on resource Y?"

It evaluates policies based on:

• User roles and group memberships
• Resource sensitivity
• Environmental context (time, location, device)
• Requested action (read, write, execute)

For permission and scope management in AI systems, the IdP's PDP can issue tokens with restricted scopes (e.g., read:inventory, write:order), enforcing the principle of least privilege on agent tool calls.

Federation Protocols are the standardized languages and flows an IdP uses to communicate with external Service Providers (SPs) or Relying Parties (RPs). They enable Single Sign-On (SSO) and secure identity assertion across domain boundaries. Key protocols include:

• SAML 2.0: XML-based, common in enterprise applications.
• OpenID Connect (OIDC): A modern, JSON-based layer on top of OAuth 2.0, widely used for web and mobile apps.
• WS-Federation: A Microsoft-driven standard.

These protocols define how an AI agent, acting on behalf of a user, can obtain a token from the corporate IdP to access third-party SaaS tools via their APIs.

Session Management handles the lifecycle of a user's or agent's authenticated interaction. It balances security and usability by:

• Creating sessions upon login
• Tracking session state and activity
• Enforcing session timeouts and absolute maximum durations
• Providing secure session termination (logout) and invalidation

For long-running AI agents, session management must handle refresh token flows to silently obtain new access tokens without requiring re-authentication, ensuring continuous operation while maintaining security controls.

An open XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). It enables web-based single sign-on (SSO) by allowing the IdP to pass a digitally signed SAML assertion containing user claims to the SP.

• Key Components: SAML Request, SAML Response, Assertion (with Authentication, Attribute, and Authorization Decision statements).
• Primary Use Case: Enterprise SSO for internal web applications.
• Flow: User accesses SP → SP redirects to IdP → IdP authenticates user → IdP sends signed assertion back to SP → SP grants access.

A simple identity layer built on top of the OAuth 2.0 protocol. It allows clients to verify the identity of an end-user based on the authentication performed by an IdP and to obtain basic profile information about the user in a REST-like manner.

• Core Artifact: The ID Token, a JSON Web Token (JWT) containing user claims.
• Vs. SAML: Uses modern JSON/REST vs. XML/SOAP; lighter and more suited for mobile and API-centric applications.
• Standard Claims: Includes sub (subject), email, name, and email_verified.
• Primary Use Case: Consumer-facing and modern application authentication, often for mobile apps and single-page applications (SPAs).

The application or service that relies on an external Identity Provider to authenticate a user. It trusts the identity assertions (SAML or OIDC tokens) issued by the IdP.

• Function: Delegates authentication to the IdP, then uses the received claims to make local authorization decisions and create a session.
• Key Responsibility: Must validate the cryptographic signature on tokens/assertions from the IdP to prevent spoofing.
• In OIDC: Called the Relying Party.
• In SAML: Called the Service Provider.
• Example: A SaaS application like Salesforce or GitHub that allows you to "Sign in with Google."

A system architecture that allows the linking of a user's digital identity across multiple separate identity management systems. It enables users to access several applications using the same credentials, managed by a trusted IdP.

• Core Principle: Decouples authentication (handled by the IdP) from authorization (handled by the RP/SP).
• Standards: Enabled by protocols like SAML 2.0, OIDC, and WS-Federation.
• Benefits: Reduces password fatigue, centralizes credential management and security policies, and simplifies user provisioning/de-provisioning.
• Trust Relationship: Requires a pre-established metadata exchange (trust) between the IdP and the SP.

An authentication scheme that allows a user to log in with a single set of credentials to multiple independent software systems. An Identity Provider is the central engine that makes SSO possible across a federation of services.

• Mechanism: After initial authentication at the IdP, the user can access all connected Service Providers without re-entering credentials.
• Session Management: The IdP maintains a central authentication session; SPs may have their own local sessions.
• Enterprise Critical: Essential for security (centralized MFA, logging) and user experience in large organizations.
• Flows: Includes SP-initiated (user clicks app link) and IdP-initiated (user starts at a portal).

The processes and tools used to create, manage, and deactivate user identities and their access rights across systems. In an IdP-centric world, this is often synchronized via protocols like SCIM (System for Cross-domain Identity Management).

• Lifecycle: Create, Enable, Disable, Delete (CRUD operations on user accounts).
• Just-in-Time (JIT) Provisioning: A user account is automatically created on the SP side upon first successful SSO login if it doesn't already exist.
• SCIM: A RESTful protocol that automates the exchange of user identity information (username, email, group membership) between an IdP (like Okta) and applications, ensuring access is granted or revoked promptly.