Enterprise SSO for AI Agents: SAML, OIDC, and Active Directory Integration

Why AI Agents Need Enterprise SSO

When AI agents operate inside an enterprise, they inherit the same security requirements as any other application. Employees expect to log in once through their corporate identity provider and access every tool, including AI agents, without re-entering credentials. Hardcoded API keys or standalone username/password forms break this expectation and create security blind spots that auditors flag immediately.

Enterprise SSO for AI agents solves three problems at once. First, it centralizes identity so that when an employee leaves, disabling their IdP account revokes access to every agent. Second, it enables role-based access, meaning a finance analyst and a DevOps engineer see different agents with different capabilities. Third, it produces an audit trail tied to real identities rather than opaque API keys.

Understanding the Authentication Flows

SAML 2.0 uses XML-based assertions exchanged between a Service Provider (your agent platform) and an Identity Provider (Okta, Azure AD, Ping Identity). The SP-initiated flow is most common: the user visits the agent dashboard, gets redirected to the IdP login page, authenticates, and is redirected back with a signed SAML assertion.

sequenceDiagram
    autonumber
    participant Caller as Caller
    participant Agent as CallSphere Agent
    participant API as CRM API
    participant DB as CRM Database
    participant Webhook as Webhook Listener
    Caller->>Agent: Inbound call begins
    Agent->>Agent: STT plus intent detection
    Agent->>API: Lookup contact by phone
    API->>DB: Read contact record
    DB-->>API: Contact and history
    API-->>Agent: Personalized context
    Agent->>API: Create call activity
    Agent->>API: Update deal stage
    API->>Webhook: Outbound webhook fires
    Webhook-->>Agent: Confirmed
    Agent->>Caller: Spoken confirmation

OpenID Connect builds on OAuth 2.0 and uses JSON Web Tokens instead of XML. It is simpler to implement and better suited for modern web applications. The authorization code flow with PKCE is the recommended pattern for browser-based agent UIs.

from fastapi import FastAPI, Request, Depends
from fastapi.responses import RedirectResponse
from authlib.integrations.starlette_client import OAuth
import jwt
import os

app = FastAPI()

oauth = OAuth()
oauth.register(
    name="azure_ad",
    client_id=os.environ["AZURE_CLIENT_ID"],
    client_secret=os.environ["AZURE_CLIENT_SECRET"],
    server_metadata_url=(
        f"https://login.microsoftonline.com/"
        f"{os.environ['AZURE_TENANT_ID']}/v2.0/.well-known/openid-configuration"
    ),
    client_kwargs={"scope": "openid email profile"},
)

@app.get("/auth/login")
async def login(request: Request):
    redirect_uri = request.url_for("auth_callback")
    return await oauth.azure_ad.authorize_redirect(request, redirect_uri)

@app.get("/auth/callback")
async def auth_callback(request: Request):
    token = await oauth.azure_ad.authorize_access_token(request)
    id_token = token["id_token"]
    claims = jwt.decode(id_token, options={"verify_signature": False})

    user_info = {
        "email": claims["email"],
        "name": claims["name"],
        "roles": claims.get("roles", []),
        "groups": claims.get("groups", []),
    }
    session_token = create_agent_session(user_info)
    response = RedirectResponse(url="/dashboard")
    response.set_cookie("agent_session", session_token, httponly=True, secure=True)
    return response

Role Mapping from IdP Groups to Agent Permissions

Identity providers organize users into groups, but your agent platform needs granular permissions. The bridge between them is a role mapping table that translates IdP groups into agent-level roles.

from dataclasses import dataclass
from enum import Enum

class AgentPermission(str, Enum):
    EXECUTE = "execute"
    CONFIGURE = "configure"
    ADMIN = "admin"
    VIEW_LOGS = "view_logs"

@dataclass
class RoleMapping:
    idp_group: str
    agent_permissions: list[AgentPermission]
    allowed_agents: list[str]

ROLE_MAPPINGS = [
    RoleMapping(
        idp_group="CN=AI-Users,OU=Groups,DC=corp,DC=example,DC=com",
        agent_permissions=[AgentPermission.EXECUTE],
        allowed_agents=["support-agent", "search-agent"],
    ),
    RoleMapping(
        idp_group="CN=AI-Admins,OU=Groups,DC=corp,DC=example,DC=com",
        agent_permissions=[
            AgentPermission.EXECUTE,
            AgentPermission.CONFIGURE,
            AgentPermission.ADMIN,
            AgentPermission.VIEW_LOGS,
        ],
        allowed_agents=["*"],
    ),
]

def resolve_permissions(user_groups: list[str]) -> dict:
    permissions = set()
    allowed_agents = set()

    for mapping in ROLE_MAPPINGS:
        if mapping.idp_group in user_groups:
            permissions.update(mapping.agent_permissions)
            if "*" in mapping.allowed_agents:
                allowed_agents.add("*")
            else:
                allowed_agents.update(mapping.allowed_agents)

    return {
        "permissions": list(permissions),
        "allowed_agents": list(allowed_agents),
    }

Token Lifecycle and Session Management

Agent sessions must handle token expiration gracefully. When an OIDC access token expires, the agent platform should use the refresh token to obtain a new one without interrupting the user. If the refresh token is also expired, redirect to the IdP for re-authentication.

Store session data in a server-side store like Redis rather than in browser cookies. This lets you revoke sessions instantly when an employee is terminated, without waiting for token expiration.

FAQ

How does SAML differ from OIDC for AI agent authentication?

SAML uses XML-based assertions and is common in legacy enterprise environments. OIDC uses JSON Web Tokens and OAuth 2.0, making it lighter and easier to implement in modern web applications. For new agent platforms, OIDC is the recommended choice because it has better library support, simpler debugging, and native mobile compatibility.

Can AI agents authenticate with service accounts instead of user SSO?

Yes, for background agents that run without user interaction, service accounts with client credentials flow are appropriate. However, any agent that acts on behalf of a specific user should authenticate through SSO so that actions are attributed to the correct identity and governed by that user's permissions.

How do you handle SSO for agents that call external APIs on behalf of users?

Use OAuth 2.0 token exchange (RFC 8693) or on-behalf-of flow. The agent exchanges the user's token for a downstream token scoped to the external API. This ensures the external service sees the real user identity and applies its own authorization rules rather than granting blanket access through a shared service account.

#EnterpriseAI #SSO #Authentication #SAML #OIDC #ActiveDirectory #AgenticAI #LearnAI #AIEngineering