ReDelegation in OuathII

Session Topic: ReDelegation in Ouath II - AuthorizationServiceUserClient

Wednesday 1I

Convener: Alan Karp

Notes-taker(s): Alan Karp

OAuth 2 provides a means for a user to delegate to a client permission to access a protected resource. However, that client frequently needs to re-delegate that permission to another client. The current specifications, http://tools.ietf.org/html/rfc6749 , http://tools.ietf.org/html/rfc6750 , are silent on how that is to be done.

There are two expired drafts to consider, http://tools.ietf.org/html/draft-richer-oauth-chain-00 , and http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00 , which are similar but not identical.

I am working with a group in HP building an infrastructure component that is currently OAuth-like (because our developers are on a tight schedule and don’t have time to learn OAuth). I would like to make it fully OAuth going forward, but we need re-delegation with sub-scoping now. The point of this session is to find out what the re-delegation spec is likely to look like, so we can make our implementation easy to change when the re-delegation spec gets published.

The pattern we’re currently using is shown in the figure. It is not OAuth because the User gives Client 1 an access token rather than a grant. The transfer to Client 2 also is an access token. The current draft proposal says we should be passing grants instead. Fortunately, in a later release we could simply change to using grants with minimal disruption. Also, in our current implementation we have combined the Authorization Service with the Resource Service, but that is allowed by the spec.