Skip to content

User Managed Access

UMA 2.0 is a new federated authorization standard protocol approved by the Kantara Initiative. It is built on top of OAuth 2.0, which enables party-to-party sharing. As shown in the diagram given below, UMA defines a workflow that creates authorization policies on a centralized authorization server for resource owners to control the access to their protected resources.


There are five main roles in a UMA workflow:

Resource owner Controls the resources that are on multiple resource servers from a single authorization server.
Authorization server Protects the resources in the resource server on behalf of the resource owner. In this scenario, WSO2 Identity Server acts as the authorization server.
Resource server Hosts the protected resources. The resource server capable of accepting and responding to requests for protected resources.
Client An application which acts on behalf of the requesting party.
Requesting party An entity that seeks to access a protected resource using a client.

Protection API endpoints

The Protection API consists of three endpoints:


Resource registration endpoint

Allows the resource owner to secure the resources using the authorization server and manage them over time.

Permission endpoint

Allows the resource server to request permission(s) when the client’s resource request is unaccompanied by a Requesting Party Token (RPT) or is accompanied by an invalid RPT.

Token introspection endpoint Allows the resource server to introspect the RPT which is required to access an UMA protected resource.

When a request is made by the resource server to the authorization server it needs to be accompanied with a Protection API Access Token (PAT) for the request to access the resource registration endpoint, permission endpoint, and token introspection endpoint.  The PAT represents the resource owner’s authorization to use the protection API. The PAT token is an OAuth access token that has the uma_protection scope.

UMA grant

A client acting on behalf of the requesting party can obtain a Requesting Party Token (RPT) from the authorization server after successful evaluation of policy conditions, scopes, claims, and any other relevant information.

What's next?