UMA 2.0 is a new federated authorization standard protocol approved by the Kantara Initiative. It is built on top of OAuth 2.0. UMA 2.0 enables clients to access protected resources which are owned by a resource owner who can set up his/her own policies.
Work Flow of UMA 2.0
Initially the Resource owner has written a set of policies to the Authorization Server. The Resource Server has registered resource sets and scopes in the Authorization Server.
- Client request access to protected resource on behalf of the requesting party.
- Resource Server registers attempted access (Resource + Scope).
- Authorization Server returns a permission ticket.
- Resource Server returns permission ticket with as_uri.
- Client validates himself as a valid user by the permission ticket with client credentials.
- Authorization Server gives RPT & PCT after gathering claims if necessary.
- Clients requests for the resource with RPT.
- Resource Server introspects RPT at the Authorization Server.
- Authorization Server returns JSON response.
- Client receives the requested resource.
Main 3 phases of UMA protocol
- Protecting a Resource
In protection a resource phase resource owner introduces resources residing on the resource server (RS) to the authorization server (AS). Authorization server has protection API which helps to protect the resource in resource server. This protection API is protected by Oauth or authentication protocol based on Oauth and also requires a protection API token (PAT) for access. The policy that pertains to access control of the resources will be configured by Resource owner.
- Get Authorization
Client request to the resource server seeking access to a protected resource under UMA. The client is required to access the authorization API exposed by Authorization server AS to obtain authorized data to be a successful access. Same as PCT this also protected by Oath and Oauth based authentication protocol and required Authorization Access Token (AAT) for access. The client needs to obtain a Requesting Party Token (RPT) on behalf of its requesting party eventually to successfully access the resource.
Some times Supply claims might be needed to obtain RPT from the AS.
- Access a Resource
After client obtain Requesting Party Token on behalf of its requesting party eventually to successfully access the resource.
Tokens which found in UMA.2.0
- Requesting Party token (RPT)
The authorization server issues access tokens that enable client access to UMA-protected resources on the requesting party’s behalf using an OAuth extension grant type called the UMA grant type. In this grant type, the client uses the OAuth token endpoint on the requesting party’s behalf. To differentiate access tokens issued through the UMA grant type from other tokens involved in the UMA process, this access token is called the requesting party token (RPT).
- Persisted claims token(PCT)
In early version of UMA they need a requesting party to perform an Oauth2.0 transaction with their clients Authorization access token or AAT. It represents the binding between the requesting party and the client. It used to call the token endpoint of the Resource server to obtain the protected resource.
If someone said my requesting party can log into the authorization server and issue Oauth tokens so it’s working fine. What does this PCT do in UMA? Simply in UMA resource owner could share with arbitrary parties using flexible claim gathering system. After all, another problem is requesting party could just get an oath taken in the first place. Then what’s the point of an extra part of the protocol?
The thing is AAT represents the combination of the requesting party and client across multiple resources, so that requesting party wouldn’t need to keep providing the same claims over to access new resources. The PCT is issued alongside the access token and it represents all of the claims that requesting party presented during the transaction. When a client comes back to ask again access it can send PCT in its initial token request. If the authorization server chooses, the claims represented by the PCT can fulfill the policies set by the resource owner.
PCT represents the set of claims collected by the authorization server during the authorization process.
- Permission ticket(PT)
The authorization server uses a permission ticket to maintain the state of requested permission information. Permission tickets are issued when an unauthorized user sends a request to the resource server. Then resource server request to the authorization server asking permission ticket. This permission ticket consisting with client id and scopes gets from authorization server.
Permission tickets MUST NOT be single-use; this is in order to allow the client to interact with the authorization server during the claims-gathering flow, which may require multiple interactions, either direct or through redirection of a requesting party.
The authorization server MUST invalidate a permission ticket when an RPT is successfully granted to a client based on this permission ticket or when the permission ticket expires, whichever occurs first. get when an RPT is successfully granted to a client based on this permission ticket or when the permission ticket expires, whichever occurs first.
- Protection API token
PAT token is an oath access token with uma_protection, used by resource server at the protection API. It consists of the resource set registration, permit, registration and token introspection endpoint.
Protection API consist of 3 end-points
- Resource registration endpoint
- Permission end-point
- Token introspection end-point
PAT binds a resource server, since the resource owner uses for resource management and authorization server the owner uses for the protection of resources on this resource server.
Features of UMA 2.0
1. Context: The right moment to make the decision to share.
2. Control: The power to share only what the resource owner desires.
3. Choice: The ability to make an independent decision.
4. Respect: Regard for one’s preferences.