Exchange Access Tokens
Enables client applications to request and obtain access tokens from the Cloudentity authorization server acting as a Security Token Service (STS).
Cloudentity 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 Cloudentity platform, and then use this token to authenticate the request.
Exchange Tokens While Enforcing Access Control
Cloudentity’s authorizers are capable of exchanging third party access tokens to Cloudentity tokens when enforcing access control.
When an authorizer receives a third-party access token that comes from a trusted IDP (authorization server), it uses its dedicated client credentials to make a request to the Cloudentity’s OAuth token endpoint and uses the OAuth Token Exchange grant type to exchange the tokens.
Token Exchange Delegation (Act-On-Behalf) and Impersonation Flows
Tokens obtained from Cloudentity 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 Cloudentity. Once Client A gets a token from the third-party authorization server, it can send a request to the Cloudentity’s OAuth token endpoint using client credentials from the Client B and passing the original token it got from the third-party authorization server. Cloudentity 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.