User Managed Access — UMA 2.0

This article is for those who have a basic understanding about OAuth protocol.

UMA 2.0 is a new federated authorization standard protocol approved by the Kantara Initiative. It is built on top of OAuth 2.0 ( OAuth 2.0 is an authorization framework which enables applications to access each others data). Using UMA 2.0 the user is given the chance to take control over their online personal data (such as identity attributes), content (such as photos), and services (such as viewing and creating status updates) from a single hub, no matter where they are located on the web. You may wonder what is the exact difference between OAuth 2.0 and UMA 2.0 . Let me explain using a simple example.

John is a university undergraduate studying overseas. He wants his social media account in photogram to access photos saved in his cloud drive storage. This task can be achieved using OAuth 2.0 . It can be simply defined as John to John sharing (a third party application accessing resources on John’s behalf). That is John sharing information with his other resources.

Imagine he wants to share his photos with his parents who are not members of photogram. John to parent sharing can’t be achieved using only OAuth. One can suggest a possible way as giving his cloud drive login credentials to his parents. This is not recommended due to security issues (password anti-patterns) and also assume that John wants his parents only to access photos in the drive, not any other resource. In such situations UMA 2.0 can be used. UMA 2.0 helps John by outsourcing of authorization and giving him the ability to control resources pro-actively and sharing resources in a selective manner.

UMA supports 3 types of sharing; person-to-self sharing, person-to-person sharing, person-to-organization sharing in a unified way from a single web-application point of control.

UMA work-flow

RPT: Requesting Party Token
PAT: Protection API Token
AS: Authorization Server
RS: Resource Server

John has set up some policies with AS to control who does what. When John’s parents want to access his resources, the client acting behalf of his parents will interact with the RS. Next the RS will obtain a permission ticket from the AS. The client needs to get a token from the AS before getting access to the resources. The AS first needs to verify if it’s really John’s parents who are requesting access to the protected resources. So for that the client interacts with the AS and provides the necessary claims that satisfy John’s policies. The client will now receive a token which it can give to the RS in order to obtain the required access.

Roles

• Resource Owner: An entity which grants access to a protected resource.
• Requesting Party: A person that seeks access to a protected resource by the support of a client. Requesting party may or may not be the same party as the resource owner.
• Client: An application that makes requests for protected resources on behalf of the requesting party with the resource owner’s authorization.
• Resource Server: A server that hosts protected resources and it has the capability of reacting to requests for protected resources.
• Authorization Server: A server that protects resources hosted by Resource Server on behalf of the owner.

Features

By using UMA 2.0 standards following features can be achieved.

1. Context: The right moment to make the decision to share.
2. Control: The power to share only what the resource owner desires.
3. Choice: The ability to make an independent decision.
4. Respect: Regard for one’s preferences.

For more detailed information on UMA 2.0 refer https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html