Skip to main content

TokenExchangeGrantHandler Class

Abblix.Oidc.Server​

Abblix.Oidc.Server.Endpoints.Token.Grants​

TokenExchangeGrantHandler Class​

IAuthorizationGrantHandler for RFC 8693 Token Exchange (grant_type=urn:ietf:params:oauth:grant-type:token-exchange).

public class TokenExchangeGrantHandler : Abblix.Oidc.Server.Endpoints.Token.Grants.IAuthorizationGrantHandler, Abblix.Oidc.Server.Common.Interfaces.IGrantTypeInformer

Inheritance System.Object → TokenExchangeGrantHandler

Implements IAuthorizationGrantHandler, IGrantTypeInformer

Remarks​

Per-format subject-token validation is delegated to keyed ISubjectTokenResolver implementations: JwtSubjectTokenResolver for the three JWT-based type URIs (access_token, id_token, jwt) and RefreshTokenSubjectTokenResolver for refresh tokens. Lookup that returns no resolver for the requested key yields invalid_request -- the library never silently accepts an unknown subject_token_type. Hosts may register additional resolvers for formats this library does not handle natively.

Authorization is structured as a monadic Bind-chain on Abblix.Utils.Result<>, mirroring JwtBearerGrantHandler: each step returns either an enriched Abblix.Oidc.Server.Endpoints.Token.Grants.TokenExchangeGrantHandler.ValidationContext or an OidcError; the chain short-circuits at the first failure. Subject-token resolution sits in the middle of the chain, so post-resolve guards (cross-client origin, typ-confusion, forwarded AD allowlist) read the resolved SubjectTokenContext directly from the context.

Supports both RFC 8693 §4.1 modes: impersonation (no actor_token; the issued token's sub equals the subject_token's subject, no act claim) and delegation (actor_token provided; the issued token's sub still equals the subject's subject, and the act claim names the actor. When the subject_token itself already carries an act chain, the new actor is layered on top -- the previous chain becomes the new actor's nested act.act).

Constructors​

TokenExchangeGrantHandler(IServiceProvider, ISessionIdGenerator, TimeProvider) Constructor​

IAuthorizationGrantHandler for RFC 8693 Token Exchange (grant_type=urn:ietf:params:oauth:grant-type:token-exchange).

public TokenExchangeGrantHandler(System.IServiceProvider serviceProvider, Abblix.Oidc.Server.Features.RandomGenerators.ISessionIdGenerator sessionIdGenerator, System.TimeProvider timeProvider);

Parameters​

serviceProvider System.IServiceProvider​
sessionIdGenerator ISessionIdGenerator​
timeProvider System.TimeProvider​

Remarks​

Per-format subject-token validation is delegated to keyed ISubjectTokenResolver implementations: JwtSubjectTokenResolver for the three JWT-based type URIs (access_token, id_token, jwt) and RefreshTokenSubjectTokenResolver for refresh tokens. Lookup that returns no resolver for the requested key yields invalid_request -- the library never silently accepts an unknown subject_token_type. Hosts may register additional resolvers for formats this library does not handle natively.

Authorization is structured as a monadic Bind-chain on Abblix.Utils.Result<>, mirroring JwtBearerGrantHandler: each step returns either an enriched Abblix.Oidc.Server.Endpoints.Token.Grants.TokenExchangeGrantHandler.ValidationContext or an OidcError; the chain short-circuits at the first failure. Subject-token resolution sits in the middle of the chain, so post-resolve guards (cross-client origin, typ-confusion, forwarded AD allowlist) read the resolved SubjectTokenContext directly from the context.

Supports both RFC 8693 §4.1 modes: impersonation (no actor_token; the issued token's sub equals the subject_token's subject, no act claim) and delegation (actor_token provided; the issued token's sub still equals the subject's subject, and the act claim names the actor. When the subject_token itself already carries an act chain, the new actor is layered on top -- the previous chain becomes the new actor's nested act.act).

Properties​

TokenExchangeGrantHandler.GrantTypesSupported Property​

The grant types supported by this component, as defined in OAuth 2.0 and OpenID Connect specifications.

public System.Collections.Generic.IEnumerable<string> GrantTypesSupported { get; }

Implements GrantTypesSupported

Property Value​

System.Collections.Generic.IEnumerable<System.String>

Remarks​

Common grant types include:

  • "authorization_code" - Authorization Code Grant
  • "implicit" - Implicit Grant
  • "refresh_token" - Refresh Token Grant
  • "client_credentials" - Client Credentials Grant
  • "password" - Resource Owner Password Credentials Grant

Methods​

TokenExchangeGrantHandler.AuthorizeAsync(TokenRequest, ClientInfo) Method​

Resolves the grant-specific input from request (authorization code, refresh token, device code, client credentials, JWT assertion, etc.) into the AuthorizedGrant that will drive token issuance, or an OidcError such as invalid_grant, authorization_pending, or slow_down.

public System.Threading.Tasks.Task<Abblix.Utils.Result<Abblix.Oidc.Server.Endpoints.Token.Interfaces.AuthorizedGrant,Abblix.Oidc.Server.Common.OidcError>> AuthorizeAsync(Abblix.Oidc.Server.Model.TokenRequest request, Abblix.Oidc.Server.Features.ClientInformation.ClientInfo clientInfo);

Parameters​

request TokenRequest​

The token request (already authenticated against the client).

clientInfo ClientInfo​

The authenticated client; used to enforce that the grant was issued to the same client that is now redeeming it.

Implements AuthorizeAsync(TokenRequest, ClientInfo)

Returns​

System.Threading.Tasks.Task<Abblix.Utils.Result<AuthorizedGrant,OidcError>>