Token and Identity Chaining Between Protected Resources in a Single ICAM Ecosystem Using OAuth Token Exchange

The OAuth 2.0 standard is used ubiquitously across the Internet for delegated authorization. MITRE has profile OAuth to describe its secure, interoperable use in enterprise environments.

MITRE’s OAuth profile does not cover cases where a protected resource (PR1) needs to call a second protected resource (PR2) in order to satisfy a query received from a client. The profile’s security requirements prevent PR1 from simply replaying the received access token. Instead, PR1 must obtain a new access token from an authorization server that it uses to access PR2.

These profiles document use of OAuth 2.0 Token Exchange (IETF RFC 8693) by protected resources and authorization servers to exchange a received access token for a new access token. We refer to the process of exchanging tokens as “token chaining.” These profiles also enable “identity chaining” by ensuring that the identities of the user, client, and protected resources are propagated in the issued access tokens, so that each protected resource can, if desired, use the set of identities to make appropriate access decisions.

Two profiles are provided. The first describes token chaining in a “single ICAM ecosystem,”where all protected resources trust the same authorization server (e.g., because they all belong to the same organization). The second describes the more complicated case of a “multi ICAM ecosystem,”where at least one protected resource trusts a different authorization server (e.g., because it belongs to a different organization).

Please note, we will be working with the standards bodies to move these concepts forward. These current profiles should be considered as informational as we seek additional feedback from subject matter experts throughout the community. We welcome your comments and suggestions.

Read the related paper on multiple ICAM ecosystems.