OAuth 2.0 is a powerful foundation for delegating access, but many real-world needs require capabilities beyond core OAuth. This chapter surveys how specialized protocols and sector profiles build on OAuth to deliver dynamic consent, interoperability, and stronger, predictable security. It introduces User Managed Access (UMA) for user-to-user sharing and policy-driven authorization, the Health Relationship Trust (HEART) profiles that tighten and align OAuth, OpenID Connect, and UMA for healthcare, and the International Government Assurance (iGov) effort that applies similar profiling to government use cases. Collectively, these initiatives narrow optionality, codify best practices, and enable independent implementations to work together reliably, even as the underlying specifications continue to evolve.
UMA extends OAuth from a model where a resource owner authorizes a client acting on their behalf to one where a resource owner can grant controlled access to another user’s client. It introduces the requesting party role, lets users “bring their own” authorization server, and uses resource sets and policies to express granular sharing rules. When a client requests a protected resource, the resource server obtains a permission ticket from the authorization server; the client then redeems that ticket by presenting required claims, after which it receives an access token reflecting the authorized scopes. The resource server validates what the token is good for (often via introspection) and serves data accordingly. This design supports dynamic discovery and registration, preserves privacy by sharing only necessary claims, enables unattended access consistent with policy, and surfaces a clear chain of delegation from resource owner to requesting party to client.
HEART demonstrates how sector profiles raise the baseline for security and interoperability. Its mechanical profiles require practices such as asymmetric JWT access tokens, token introspection and revocation, service discovery, dynamic registration, strict redirect URI matching, mandatory state, public key–based client authentication, signed ID tokens, and optional encrypted JWT UserInfo, with UMA usage aligned to these requirements. Its semantic profiles standardize scopes, claims, and permissions for FHIR-based healthcare APIs so clients can predictably map authorization to clinical data. iGov applies a similar profiling approach for government identity and access, leveraging many HEART decisions to shape durable, interoperable public-sector systems. Together, these efforts show how constraining flexible standards yields consistent, secure deployments that can still interoperate with the broader OAuth ecosystem.
Components of the UMA protocol
The UMA protocol in detail
FAQ
What is User Managed Access (UMA) and how does it extend OAuth 2.0?
UMA is a protocol built on top of OAuth 2.0 that enables user-to-user delegation and dynamic consent management. It introduces the requesting party (RqP) role and lets a resource owner bring their own authorization server (AS) to control access to resources on a resource server (RS). Unlike OAuth’s “Alice-to-Alice” model, UMA enables “Alice-to-Bob” sharing across different clients and domains.Who are the key roles and tokens in UMA (PAT, AAT, RPT)?
- PAT (Protection API Token): Access token the RS obtains to call the AS’s protection APIs (register resource sets, request permission tickets, introspect tokens).- AAT (Authorization Access Token): Client-side token intended to bind the RqP to the client and AS in UMA 1.0; may be deemphasized or removed in newer versions.
- RPT (Requesting Party Token): The access token the client obtains from the AS and presents to the RS to access the protected resource.
How does the UMA flow work at a high level?
1) The resource owner introduces the RS to their AS (issuer discovery). 2) The RS discovers the AS and registers as an OAuth client, then obtains a PAT. 3) The RS registers resource sets and the owner configures policies. 4) A client requests a resource; the RS identifies the target resource set and gets a permission ticket from the AS. 5) The RS returns a 401 with WWW-Authenticate: UMA containing the ticket and AS location. 6) The client discovers/registers with the AS and presents the ticket. 7) If more information is needed, the AS returns need_info and the client gathers claims (possibly via redirecting the RqP to the AS using OpenID Connect). 8) With sufficient claims, the AS issues an RPT. 9) The client calls the RS with the RPT; the RS introspects the token (using the PAT) and, if authorized, returns the resource.What are “resource sets” and why are they important in UMA?
Resource sets are server-registered groupings of protected resources with associated scopes (capabilities). The RS registers them at the AS (using the PAT), receives an identifier and management URL, and links policies to them. This lets the owner express granular, policy-driven access (“who can do what”) across logical bundles of data.What is a “permission ticket” in UMA and how is it used?
A permission ticket is a handle the RS obtains from the AS to represent a specific access request (resource set + proposed scopes). The RS returns this ticket to the client via WWW-Authenticate: UMA. The client then presents the ticket to the AS to obtain an RPT, potentially after supplying additional claims.How does claims gathering work in UMA?
When the client presents the ticket, the AS evaluates policy and may respond with need_info specifying required claims (names, formats, acceptable issuers). The client can submit verifiable claim tokens directly or redirect the RqP to the AS’s claims endpoint for interactive login (often via OpenID Connect). The AS binds collected claims to the ticket; once satisfied, it issues the RPT.How does a UMA resource server validate a client’s access token?
Typically via token introspection at the AS using the RS’s PAT. UMA extends the introspection response with a permissions object listing resource_set_id, authorized scopes, and expirations. The RS decides whether the presented RPT satisfies the current request.What is HEART and why does it matter?
HEART (Health Relationship Trust) is an OpenID Foundation working group that profiles OAuth, OpenID Connect, and UMA for healthcare. It narrows optionality, codifies best practices, and raises baseline security and interoperability so apps, authorization servers, and APIs from different vendors work together securely—empowering patients and providers to control data access.What does HEART require in its mechanical profiles for OAuth, OpenID Connect, and UMA?
- OAuth: Asymmetrically signed JWT access tokens; JWK key registration for all clients (no client secrets); discovery, introspection, revocation, and dynamic client registration; strict state usage and exact redirect URI matching.- OpenID Connect: Asymmetrically signed ID tokens; signed UserInfo (with optional encryption); support for request objects validated with client keys.
- UMA: Conformance with the above plus dynamic resource registration and RqP claims gathering via interactive OIDC login.
OAuth 2 in Action ebook for free
