OAuth Token Exchange - Impersonation and Act-On-Behalf Flows

Enables client applications to request and obtain access tokens from the SecureAuth platform authorization server acting as a Security Token Service (STS).

SecureAuth validates tokens provided to it and issues new tokens in the response, which enables client applications to obtain appropriate security tokens for resources that are within distributed environments. In other words, a client application may request access to resources with an access token from a third-party authorization server, exchange its token to an access token provided by the SecureAuth platform, and then use this token to authenticate the request.

Tokens obtained from SecureAuth allow their bearers to either impersonate or act on behalf of the original service.

A common use case for the delegation is to allow a resource (actor) to make calls to a backend service on behalf of the requesting user (subject). In practice, the resource needs an access token of the requesting user without direct user interaction. It can be accomplished by leveraging the JWT Bearer Flow or Client-Initiated Backchannel Authentication (CIBA) flow. If the trust is implicit and the authorization of the user can be assumed to be acted on, the JWT Bearer Flow can be used. In case there is a need of an explicit trust, a higher security level is needed and you need obtain an authorization from the end user. In such scenario, you can use the CIBA flow to fetch authorization from the user from a different consumption device.

Organizations may want to utilize the token exchange impersonation flow, where a client application A is registered within the third-party authorization server. Client application B is registered within the SecureAuth platform. Once Client A gets a token from the third-party authorization server, it can send a request to the SecureAuth's OAuth token endpoint using client credentials from the Client B and passing the original token it got from the third-party authorization server. SecureAuth validates the request and mints a token that is used to authenticate the client to access protected resources. In this setup, Client A impersonates Client B, since the resource server won't be able to distinguish between Client A and Client B when A makes a request to the resource server.