{"id":11196,"date":"2018-09-10T15:25:10","date_gmt":"2018-09-10T14:25:10","guid":{"rendered":"https:\/\/www.riskinsight-wavestone.com\/?p=11196\/"},"modified":"2020-01-02T11:42:14","modified_gmt":"2020-01-02T10:42:14","slug":"demystifying-uma2","status":"publish","type":"post","link":"https:\/\/www.riskinsight-wavestone.com\/en\/2018\/09\/demystifying-uma2\/","title":{"rendered":"Demystifying UMA2.0"},"content":{"rendered":"

This June at <\/span>#Identiverse<\/span><\/a> in Boston I had quite an epiphany during <\/span>Eve<\/span><\/a> and <\/span>Mike<\/span><\/a>\u2019s session.\u00a0<\/span>I finally realized that <\/span>User-Managed Access 2.0 protocol (aka UMA2.0) is not that complicated to understand <\/b>and VERY similar to some OAuth2 flow we all know. Let me try and convince you.<\/span><\/p>\n

 <\/p>\n

UMA2.0 : an extension of OAuth2<\/h2>\n

Before taking the shovel and digging deeper, remember that UMA2.0 was actually designed as a new grant type of OAuth2 and not as a new protocol. If you already know <\/span>OAuth 2.0<\/span><\/a>, then you can understand UMA2 in less than 10 minutes. I promise.<\/span><\/p>\n

Here’s the UMA2.0 grant type in one typical flow:<\/span><\/p>\n

\"\"<\/figure>\n
    \n
  1. The client initiates a request against the resource without a token<\/span><\/li>\n
  2. The resource server requests a permission ticket from AS by sending it the requested resource details (requested scopes and resource registered id)<\/span><\/li>\n
  3. The resource server sends back an error response including the AS location and a permission ticket<\/span><\/li>\n
  4. The client optionally requests a Requesting Party Token (RPT, see it as UMA’s custom form of an access token) directly against the authorization server’s token endpoint using the permission ticket. <\/span><\/li>\n
  5. The client redirects the user agent to the authorization endpoint on the Authorization Server to request a token and the authorization server interacts with the requesting party to gather whatever is needed to take an authorization decision (authentication, attribute gathering, etc.) <\/span>(wait, this sounds familiar)<\/span><\/i><\/li>\n
  6. The authorization server redirects the user-agent to the client redirection URI including an updated permission ticket <\/span>(I know this\u2026)<\/span><\/i><\/li>\n
  7. The client requests a requesting party token against the authorization server’s token endpoint using the updated permission ticket <\/span>(I definitely remember now\u2026)<\/span><\/i><\/li>\n
  8. The authorization servers responds with the RPT and a PCT (Persisted Claims Token, details follow) <\/span>(so one ephemeral code against two tokens, mmh, been there\u2026)<\/span><\/i><\/li>\n
  9. The client requests the resource server with the RPT (UMA2 actually recommends to conform to plain OAuth2 practice like <\/span>RFC 6750 Bearer Token usage<\/span><\/i><\/a> or <\/span>PoP<\/span><\/a>)<\/span><\/li>\n
  10. The resource server optinnaly requests the Authorization server to validate the RPT (using the OAuth2 introspection endpoint) (following <\/span>RFC 7662 Token Introspection<\/span><\/i><\/a> extended by UMA2) or can do that locally depending on the token\u2019s format.<\/span><\/li>\n<\/ol>\n

     <\/p>\n

    Do you see the authorization code flow? Let me highlight it to you:<\/span><\/p>\n

    \"\"<\/p>\n

    Yes, steps 5 to 8 are VERY much like the <\/span>OAuth2 authorization code grant<\/span><\/a>.<\/span><\/p>\n

    If you agree to the following approximations, there are really no other major differences:<\/span><\/p>\n