UMA (User-Managed Access) 2.0: How It Works And What It Can Be Used For

Written by Aniket Kambli | Published 2021/06/01
Tech Story Tags: user-managed-access | backend | api | software-architecture | authentication | authorization | oauth | optimization

TLDR OAuth is used for authorization purposes. UMA can be used to give access to someone without giving their credentials. OAuth allows you to link your amazon wallet with your swiggy without giving them the amazon credentials. The following is the flow that UMA follows: The resource owner set’s some permission on who can access the resources from the resource server and also controls the permissions on the Authorization server. The requesting party is the application to whom the user grants permission to access resources on behalf of the user. The requesting party will be someone (not you) wants to link amazon pay wallet with their Swiggy account.via the TL;DR App

Before we get started with UMA, i would like to introduce OAuth, OAuth is used for authorization purposes. Suppose someday you visit a website which suggests you jokes, and you want to share this jokes with your friends so one option is to type everyone’s email and send them this website to them or connect this website to your Gmail account and let this website access your contacts but you can’t trust this website so you cannot give it your email and password. This is where OAuth comes into the picture rather than giving your website this email and password you get redirected to the website (Gmail) and you log in to that website and then give your client (jokes website) access to just your contacts and nothing else. 
Now consider the example of google drive on which you have an account and you want to share some pictures from google drive with your parents so in this case you cannot use OAuth as you will need to give your gmail id and password to your parents to get these photos this is where the UMA comes into picture. Before we get started with UMA, let’s discuss some terminologies related to it.
Resource Owner: This is the user who has an account in the authorization server and will log in to the authorization server to give access to the client application for accessing resources.
Authorization server: This is the server responsible for authorizing the user and checking if the user is who he claims to be.
Resource server: This is the server where the resources are located which the client wants to access.
Client: This is the application to whom the user grants permission to access resources from the resource server on behalf of him.
  • RPT: Requesting Party Token
    PAT: Protection API Token
    AS: Authorization Server
    RS: Resource Server
Consider the example in which you want someone(requesting party) to access your private resources stored using Resource server without giving your credentials. Suppose you want to link amazon pay wallet on swiggy
Here if you want to link your amazon wallet then you can use OAuth for that where you will get redirected to the amazon’s website and you enter the amazon credentials and you have successfully linked your amazon pay wallet with your swiggy. On the other hand if you want someone else to link your amazon wallet with their swiggy without giving them the amazon credentials then you can use UMA.
Look at the above image if we try to relate our swiggy example with this one then the requesting party will be someone (not you) wants to link the amazon pay wallet with their swiggy account, the client will be swiggy, Resource server and authorization server are same in this case i.e. amazon, the resource owner is you who owns the amazon account.
The following is the flow that UMA follows:
  • The resource owner set’s some permission on who can access the resources from the resource server and also controls the permissions on the Authorization server.
  • The authorization server is responsible for protecting the resources stored on Resource server by checking the permission set by the user.
  • Now whenever a requesting party is trying to access the private resource on the behalf of the user, the client takes this requesting party credentials and then authenticates this requesting party to check if this requesting party is given access by the resource owner or not, it checks this with the authorization user.
  • Once the requesting party and the client has been identified to be the correct one’s then the client is given access to the resources of the resource owner.
So this is how you can use UMA to give access to someone without giving them their credentials, UMA can be used for person-to-person sharing, person-to-self and person-to-organization.

Written by Aniket Kambli | Member of technical staff at www.udgama.com
Published by HackerNoon on 2021/06/01