OAuth: New Chain Grant Type

I posted a new Internet Draft, the "Chain" grant draft [now expired] today for the consideration of the OAuth2 working group. The specification defines a new grant type that enables an OAuth protected service to in turn act as an OAuth client to another OAuth protected service. The grant type allows the first server to exchange the current oauth access token for a new token valid on the target service. This grant type makes it possible for multiple connected services to interact in a message bus or chain.

Introduction

The use case for this proposal springs from inter-service communication or messaging scenarios. Currently many applications use SOAP based services, such as in WS-SecureConversation which have ways to handle authorization and identity propagation between service end-points.

Now, that REST is becoming popular, the question arises as to how to properly propagate identity without heavier SOAP messages. Since REST relies solely on HTTP, how do you pass identity assertions?

Aside: Note that I'm not saying REST is better or worse than SOAP, merely that REST needs a way to propagate identity just like SOAP.

OAuth seems to have some answers to this question by allowing services to use tokens to access protected resources. It also allows for SAML Assertions to be exchanged for OAuth bearer tokens. But what happens if multiple services are chained together in a bus? What happens when the next pairwise exchange that needs to occurs? The original user and/or SAML bearer assertion is no longer available.

As currently specified, the OAuth framework handles only one client-service pair relationship, it cannot handle multiple 'chained' service calls.

Let's take a look at the following scenario:

In the above picture, we see a user, accessing a web site that offers banking statement aggregation. The user, having previously authenticated to "Bank Svc" (the Bank), indicates to the Aggregator that they would like to include information from the Bank. The Aggregator site accesses the token service for the Bank. The Bank Auth/Token Service, takes into account the user context (UC), the client credentials (C1C), and a requested scope and if successful, returns an access token (AT1).

Note: for those paying attention, there is often a 3-legged flow involving the end-user, but I am simplifying for brevity.

Once the access token AT1 is returned, the Aggregator is free to access the Bank as authorized by the user and the Bank's Authorization Service.

So far, we have demonstrated a successful capability to access a REST based service using a token that embodies both a user context, a client context, and a scope. But what happens, as is common in messaging systems, if the Bank in turn wants to access another service provider (e.g. Trader). Since there is no longer any direct user involvement, can the Bank obtain an access token for the Trader service?

The Chain Grant Profile

In this scenario, the Bank is acting under some high level of trust with the Trader service. E.g. the Bank owns the Trader service. In this case, the Trader is willing to trust the Bank application to indicate that it has the authorization to work on behalf of a user. In this flow, the Bank application contacts the authorization service for the Trader, and requests an access token using a new grant_type called "chain". In the "chain" grant type, instead of passing a user context, or an authorization code, the client instead passes an access token received from the Aggregator.

In this flow, the Bank provides its own client context (C2C) for its application (now acting as an OAuth client), and the access token (AT1) that it received from the aggregator is included in a POST to the Trader authorization/token service. This allows the Trader's authorization/token service to either parse AT1 or contact the Bank's authorization service for more information. In this case, AT1 embodies both the original user context (UC) plus the Aggregator (C1C). After successful processing, the Trader authorization service issues AT2, which combines C2C and AT1 as shown below.

In multi-node scenarios, this process could be repeated indefinitely leaving a traceable security path to the originating user along a pair-wise trust path between services.

Token Issues

One thing the draft specification does not address is how the trader's OAuth authorization/token service is able to parse the bank's authorization token (AT1). This likely will be handled in upcoming OAuth token specifications standardizing formats and claims included in tokens.

As always...comments and feedback are appreciated.

**Update**
Unfortunately due to IETF policy, the chain draft has now expired. If anyone is still interested in seeing the draft, please let me know by commenting.