Which statements are correct in relation to an OAuth2 token exchange impersonation pattern? A) The client may want to act as the subject on another…

The OAuth 2.0 Token Exchange impersonation pattern allows a client (the "actor") to obtain a token to access a downstream service while acting on behalf of a user (the "subject"). Therefore, the client's goal is to act as the subject on another service (A). The token exchange request itself, as defined in RFC 8693, involves the client presenting a subjecttoken (representing the user) and typically an actortoken (representing the client itself) to clearly define the impersonation context (D).

B. A subject acting on behalf of another subject describes a delegation pattern, which is a different use case from impersonation.

C. The request must identify both the subject being impersonated and the actor doing the impersonating; a subjecttoken alone is insufficient.

1. Internet Engineering Task Force (IETF), RFC 8693, "OAuth 2.0 Token Exchange," Section 1, "Introduction." This section describes the impersonation use case where a service acts on behalf of a user.

2. Internet Engineering Task Force (IETF), RFC 8693, "OAuth 2.0 Token Exchange," Section 2.1, "Request." This section defines the subjecttoken and actortoken parameters used in the exchange to represent the subject and the acting party, respectively.

3. Ping Identity, PingAM Documentation, "OAuth 2.0 Guide," Chapter: "OAuth 2.0 Token Exchange," Section: "Impersonation." This section details PingAM's implementation of the impersonation grant type, aligning with RFC 8693.