...
Although UMA's primary use cases have centered on individual people, the "users" who managed access to their own online resources, the UMA notion of authorization as a service also has relevance to modern enterprises that must secure APIs and other web resources in a developer-friendly way.
...
Using current WAM solutions to provide API security can be unfriendly to developers, complex, expensive, and likely proprietary (outside of the use of XACML). Mobile client applications clients struggle to deal with XML-based and SOAP-based security mechanisms.
...
WAM solutions are not fully agnostic as to authentication method. WAM solutions previously could make simplifying assumptions about how users authenticate (typically username and password into a web app). With mobile applications, game consoles, and other device types, and with strong authentication needs increasing, old assumptions are no longer viable.
APIs by their nature are subdivisions of functionality exposed at a single domain, and would map well to arbitrarily fine-grained policy, for example, at the call or even parameter level. However, outside the use of XACML, authorization policy granularity is coarse in traditional solutions: group filtering or URL regular expression matching at most.
Proposed Improvements
UMA makes the following solutions possible.
As a profile of OAuth 2.0 (IETF RFCs 6749 and 6750) 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 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 set and scope descriptions creates an access control mechanism that enables control over specific resource endpointsAPI scopes (completely customizable buckets of API functionality), not just domains. With UMA, developers can handle authorization tasks by calling simple REST/JSON 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 the flexibility in policy expression and evaluation through XACML, other declarative policy languages, or procedural code as warranted by conditions.
UMA inherits an authentication-agnostic outlook from its OAuth baseagnosticism 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.
...