Since I’m editing the User Managed Access (UMA) Core spec, I always seem to be getting questions about UMA.  Also I’ve noticed that some folks in the IETF OAuth2.0 WG have not really understood the UMA flows (not suprising, since the UMA Core Rev 5C is now over 40 pages long). So I thought a very high level tutorial would benefit lots of people.

So here goes Part 1 of the tutorial.

 

 

 

 

 

 

When a Requester (acting on behalf of a Requesting Party) seeks access to resources sitting at the Host, the Requester must obtain an OAuth2.0 token from the Authorization Manager (AM).  In this case the Requester is behaving like an OAuth Client, while the AM is behaving like an OAuth2.0 Authorization Server (AS). The resulting token is referred to in the UMA specs as the Authorization API Token (AAT).  This token allows the Requester to use the other APIs at the AM at a later stage. It signals authorization by the AM for the Requester to access the other APIs at the AM.

After the Requester gets its own AAT token, it must now get another token specific to the Requesting Party (call him Bob).  This token is referred to as the Requester Permission Token (RPT).  Later when Bob (the Requesting Party) is seeking to access resources to at the Host (e.g. MyCalendarsz.com) by employing the Requester (e.g. TripItz.com), the requester must forward both tokens (the AAT and the RPT tokens) to the Host.

The reason why two tokens are needed is that there might be multiple Requesting Parties (eg. Bob, Billy, Becky, etc) at the same Requester (TripItz.com) seeking to access the same resources at the same Host. However, the Requester needs to be authorized only once by the AM to access the AM’s APIs.

[In the next post, we’ll see how the Host has to do the same basic registration to the AM]