SSO for AI Agents with OpenID Connect
On this page
Single Sign-On for AI agents means that users can use an active session with a common identity provider to authenticate to an AI agent and via an AI agent to other systems (APIs). In other words, SSO for AI agents has two aspects:
- SSO when the user logs in to an AI agent.
- SSO when the AI agent performs tasks on behalf of that user.
This article primarily focuses on the second point because it is the most notable part of an SSO process for AI agents. This article thus discusses an approach to utilize OpenID Connect and a new form of OAuth token exchange, to maintain user identities across trust domains without having to prompt users multiple times for authentication or consent.
For the sake of clarity, the article also includes a short note about how to bootstrap the flow and how to use OpenID Connect for the initial login.
Learn the basics of SSO
For a general overview of SSO, see the Introduction to SSO article.
The AI Agent SSO Process
The core asset of OpenID Connect is the ID token that conveys user data. The SSO process for AI agents with OpenID Connect first needs to obtain the ID token. AI agents then can use it to request an intermediate token to authenticate users for the agentic workflow. In essence, the SSO process looks like the following.
- First, the AI agent retrieves the ID token during the login through an OpenID Connect flow. This is where conventional SSO takes place.
- Then, the AI agent uses the ID token in token exchange flows to get a new set of tokens that preserve the user identity.
SSO for Logins to AI Agents
As AI agents are applications at the bottom, developers can apply existing approaches for OpenID Connect when implementing SSO. Consequently, developers should fall back to the best practices for implementing OpenID Connect in the corresponding technology stack to authenticate users and bootstrap SSO for the agentic workflows of AI agents. Developers can, for example, utilize established approaches like SSO for Web Apps or SSO for Mobile Apps to authenticate users and get an ID token for AI agents.
Established approaches utilize the browser for logins and SSO. This means, that when users start an AI agent and log in, the AI agent triggers a browser window to redirect a user to their IdP for authentication - just like other applications do. If there is a valid session with the IdP, the user gets automatically logged in (SSO) and the OpenID provider returns an ID token to the AI agent.
Once the AI agent retrieves the ID token, it can use the ID token to bridge access to a foreign trust domain with a multi-step flow.
SSO Across Trust Domains
The following diagram illustrates the SSO process for AI agents across trust domain.
As mentioned before, AI agents can utilize existing approaches for user authentication and SSO to request and receive an ID token. The details differ depending on the approach but in the diagram above they all end with the AI agent getting an initial ID token from the OpenID Provider in trust domain A (IdP A). At that point, the user is logged in to the AI agent.
AI agents can also use the same mechanisms to authenticate users at the authorization server (or OpenID provider) in the foreign trust domain. This entity is marked as the Resource AS in the diagram. For SSO to work, the Resource AS needs to federate with the user's IdP (IdP A in the diagram). However, there are other, more user-friendly ways to provide SSO for this use case.
To utilize SSO and maintain the user identity for downstream calls in a different trust domain (trust domain B), the AI agent can check whether the Resource AS, supports the Identity Assertion JWT Authorization Grant. For example, it can check the authorization server metadata. Alternatively, the AI agent could be configured to run the ID-JAG flow for certain foreign trust domains.
The ID-JAG flow involves a new token exchange flow where the AI agent exchanges its ID token for a new credential, a cross-domain authorization grant called Identity Assertion JWT. This cross-domain authorization grant allows the AI agent then to request access tokens on behalf of the user, i.e. log in as the user in the foreign trust domain.
A Multi-step Flow
To utilize SSO and maintain the user identity for downstream calls in a different trust domain (trust domain B), the AI agent needs to apply a new token exchange flow where it exchanges the ID token for a new credential (authorization grant). For that it performs the following steps.
- The AI agent uses the ID token to request an authorization grant for another trust domain from its OpenID Provider.
- The OpenID Provider validates the ID token, its access control policies regarding the foreign trust domain, and if allowed, returns an authorization grant.
- The AI agent requests new tokens from the foreign trust domain in the name of the user with the help of the authorization grant.
- The AI agent can continue to act on behalf of the user at the services of the other trust domain.
The new access is based on the authentication event and ID token that the AI agent previously initiated (SSO). There is no need for the AI agent or OpenID Provider to initiate new authentication requests or interact with the user.
In a multi-domain setup the user identifiers may differ between the domains. This means that, as part of step 3, the authorization server in the foreign trust domain may have to map user identities to its own vocabulary and identifiers. The AI agent then receives an access token (but no ID nor refresh token) conveying a user identity that the downstream services understand.
After step 4 the AI agent has multiple tokens from multiple trust domains:
- ID Token (trust domain A)
- Access Token (trust domain A, optional)
- Refresh Token (trust domain A, optional)
- Authorization Grant (trust domain A)
- Access Token (trust domain B)
The AI agent can renew the access token for the foreign trust domain with the cross domain authorization grant. It can also use the ID token to request a new authorization grant.
The Token Exchange Request
The following are the parameters of the token exchange request that is used to prepare for accessing data on behalf of the user in a foreign trust domain.
| Parameter Name | Description | Comment | Example |
|---|---|---|---|
requested_token_type | Specifies the type token that the OpenID provider should return. | The ID Assertion JWT is a type of token that allows a client to authenticate the user at the authorization server in a foreign trust domain. | requested_token_type=urn:ietf:params:oauth:token-type:id-jag |
audience | Specifies the expected consumer of the new token. | This is the issuer identifier of the target authorization server in the foreign trust domain. | audience=https://mcp.company.example/ |
subject_token | Specifies the security token that allows the OpenID provider to identify the subject. | The ID token of the user that the AI agent retrieved when it authenticated the user. | subject_token=eyJraWQiOiItMTQ5NzQx... |
subject_token_type | Specifies the type of security token used in the subject_token parameter. | Token Exchange (RFC 8693) supports exchanging different kinds of tokens. ID tokens are one example useful in the context of SSO for AI agents. | subject_token_type=urn:ietf:params:oauth:token-type:id_token |
resource | The identifier of the resource server in the foreign trust domain. | The resource server that an AI agent may call is, for example, the URL of the MCP server. | https://org.example/mcp |
scope | The scope of the requested access. | The scope that the AI agent requests to be able to access the resources foreign trust domain. | payments_read |
The Role of the Authorization Grant
As the ID token is from a different trust domain than the target service (and because the ID token is only valid for the AI agent), the AI agent cannot use the ID token directly to request new access tokens in a foreign trust domain. Therefore the AI agent requests a new, temporary credential from its OpenID Provider that is valid in the foreign trust domain.
This temporary credential eventually grants the AI agent permission to act on behalf of the user to some extent (scope, time). In other words, the credential represents an authorization grant comparable to the one that the AI agent received when requesting the ID token in the first place.
The Role of the OpenID Provider
The OpenID Provider is responsible for collecting any user consent including consent to the AI agent accessing data in other trust domains. It is the place where an administrator configures the policies of which AI agents, when and under what circumstances they may request a grant for a foreign trust domain based on a valid ID token. These policies are reflected in the authorization grant.
The Token Request
| Parameter Name | Description | Comment | Example |
|---|---|---|---|
grant_type | The type of authorization grant that the client provides in the request to get the access token. | The most famous authorization grant is the authorization code. | urn:ietf:params:oauth:grant-type:jwt-bearer |
assertion | Holds an assertion grant. | If the grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, the assertion contains a JWT. | eyJ0eXAiOiJvYXV0aC1... |
The assertion represents the user's grant to the AI agent to request access tokens on the user's behalf. When using JWT User Assertions the assertion is a JWT. The profile Identity Assertion JWT Authorization Grant further defines the content and processing of the JWT.
Summary
To implement SSO for AI agents you need support for newer standards that can span trust domains. You can then implement SSO for various agentic use cases. You can then enable new types of agentic federation:
- SSO from your authorization server to a cloud identity provider, to silently update your protected resources without prompts.
- SSO from your authorization server to a partner's IdP, whose administrator can safely grant partial access to your resources.
Judith Kahrer
Product Marketing Engineer at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free TrialWas this helpful?
