Re-Delegation and Revocation with OAuth

Re-delegation and Revocation with OAuth 2

Wednesday 1C

Convener: Alan Carp

Notes-taker(s): Alan Carp

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

The motivating example is company A contracting with company B to allow employees of A to use services provided by B.  Today, we federate identities so that the identities of A's users appear in B's environment.  There are many problems with this approach that we can avoid by an approach called Federated Access Management (FAccM).  However, FAccM requires that we create delegation chains, but there are no standards for doing that with OAuth.

In FAccM, company B gives company A a token with a scope of all the permissions covered by the contract.  Company A delegates a subscope token to one of its employees, say a manager, who further delegate a sub-subscope token to a user.  When that user submits a request with this token, some party on the receiving side verifies that the request is authorized by the token and that the delegation is proper.

There are currently no standards specifying how to build such delegation chains.  In this session we discussed three options.

1. Alice, the holder of an access token, can present that token to the Authorization Service (AS) and request a new token with a subscope.  Alice can then give that token to Bob.  Bob can further delegate to Carol using the same process.  The AS keeps track of the delegation chain and revokes any tokens downstream from a revoked token.

2. The token is a JWT specifying a scope and a public signing key.  It can only be used in a request signed by the corresponding private signing key.  Alice, the holder of such a token, can create a new token that includes a potentially one-off public key she gets from Bob.  She proves the delegation is valid by including a copy of her token in the metadata.  Bob's request can be validated by checking that the request and each nested token is properly signed and that all delegations are valid subscopes.  Tokens are revoked by telling the verifer not to honor a token with a specific GUID or any tokens delegated from it.

3. This proposal is not fully spelled out.  The basic idea is to use hashes of tokens and metadata instead of signed JWTs.  Other than that, the basic mechanism is the same as in 2.

We produced a table of advantages and disadvantages.

1)

Advantages: Close to OAuth standard and flows.

Disadvantages: Must be able to reach AS to delegate, metadata separate from token

2)

Advantages: Don't need to reach AS to delegate, can include lots of metadata, well understood because it's like what was done with SAML.

Disadvantages: Signing complexity, size of tokens, verification cost

3) 

Advantages: Don't need to reach AS to delegate, size more flexible than JWT because no standard for mandatory fields

Disadvantages: cost of hash, size of tokens, verification cost

We ended with a vote.  Only three of the seven people present voted, but they all voted for #3.  I didn't vote, but I would have picked #1.