There’s now an OAuth working group draft of the OAuth 2.0 Token Exchange specification, which provides Act-As and On-Behalf-Of functionality for OAuth 2.0. This functionality is deliberately modelled on the same functionality present in WS-Trust.
Here’s a summary of the two concepts in a nutshell: Act-As indicates that the requestor wants a token that contains claims about two distinct entities: the requestor and an external entity represented by the token in the act_as parameter. On-Behalf-Of indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the on_behalf_of parameter.
This draft is identical to the previously announced token exchange draft, other than that is a working group document, rather than an individual submission.
This specification is available at:
An HTML formatted version is also available at:
1 Comment » Posted under Claims & JSON & OAuth & Specifications
One Response to “Working Group Draft for OAuth 2.0 Act-As and On-Behalf-Of”
amiri-ge on 28 Oct 2015 at 7:53 am #
I have some questions about your “OAuth 2.0 Token Exchange” draft.
In section 2 the draft says “The request JWT MUST be signed by the issuer so the identity of the requesting party can be validated”.
And in section 2.1 it mentions that the “act_as” parameter, which is part of the request described above, “MUST contain a Security Token that is a JWT.”
Here’s what I find confusing: if the request is signed by the issuer, then the issuer must also populate the “act_as” property in the request. So how would the requester tell the issuer what JWT it wants in the “act_as” property?
My expectation for act as functionality is more along these lines:
1. The requester already has some token that belongs to the identity they wish to impersonate (e.g. the requester is a back-end service that verifies the tokens).
2. The requester can use the token described above in a request to alter the scopes and conditions of the token so that it can use it to consume some other resource.
3. The requester must prove to the STS that it has the privilege to make the request.
If anything, the requester should sign the security_token_request to authenticate itself and prove that the request is legitimate. But even this seems to go against the grain of OAuth which:
1. In general relies on the transport to provide mitigation against tampering and information disclosure.
2. Authenticates clients using their id and secret.
I would appreciate your thoughts on this matter. Perhaps there might be some way for us to connect so that we can have this discussion using a more convenient medium.