As a profile of OAuth 2.0 that is complementary to OpenID Connect, UMA defines RESTful, JSON-based, standardized flows and constructs for coordinating the protection of any API or web resource in a way that will be familiar to any developer already acquainted with OAuth. Mobile developers accept technologies that use HTTP and JSON at their core.
UMA’s notion of machine-readable resource sets and scope descriptions creates an access control mechanism that enables control over specific API scopes (customizable buckets of API functionality), not just domains. With UMA, client app developers can handle authorization tasks by calling simple JSON/REST endpoints; administrators don’t have to deploy a web server agent or reverse proxy to enable centralization.
UMA defines interfaces between authorization servers and resource servers that, by default, enable centralized policy decision-making for improved service delivery, auditing, policy administration, and accountability, even in a very loosely coupled “public API” environment. Custom profiles enable flexibility to move the decision-making line outward to distributed applications, to account for local preferences in API ecosystems. UMA does not standardize a policy expression language, enabling flexibility in policy expression and evaluation through XACML, other declarative policy languages, or procedural code as warranted by conditions.
UMA inherits authentication agnosticism from OAuth. It concentrates on authorization, not on authentication. It has been profiled to work with OpenID Connect to gather identity claims from whoever is attempting access, and enables true claims-based authorization (with simple group or role based policies a natural subset).
Review the complete Enterprise UMA Solution Scenario on the Kantara webpage.