- The resource owner authorizes protected resource access to clients used by entities that are in a requesting party role. This enables party-to-party authorization, rather than authorization of application access alone.
- The authorization server and resource server interact with the client and requesting party in a way that is asynchronous with respect to resource owner interactions. This lets a resource owner configure an authorization server with authorization grant rules (policy conditions) at will, rather than authorizing access token issuance synchronously just after authenticating.
For example, bank customer (Resource Owner) Alice with a bank account service (Resource Server) can use a sharing management service (Authorization Server) hosted by the bank to manage access to her various Protected Resources by spouse Bob, accounting professional Charline, and bank account aggregation company DecideAccount, all using different client applications, to view account data and get access to payment or withdrawal functions.
An OPTIONAL second specification, UMAFedAuthz, defines a means for an UMA-enabled Authorization Server and Resource Server to be loosely coupled, or federated, in a Resource Owner context. UMA 2.0 Grant for OAuth 2.0 Authorization specification, together with UMAFedAuthz, constitutes UMA 2.0.
More Information#There might be more information for this subject on one of the following:
- Permission ticket
- Persisted Claims Token
- UMA 2.0
- Web Blog_blogentry_110717_1
- [#1] - User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization - based on information obtained 2017-07-10-