/
Security Notice: Pass the Permission Ticket

Security Notice: Pass the Permission Ticket

Owned by Alec Laws
Mar 19, 2025
7 min read

This is a notice of an identified vulnerability in the UMA 2 specification. Please refer to the following details, including recommended next steps for mitigation if your implementation is affected. 

Many thanks to Gabriel Corona for his efforts in finding, documenting and explaining these issues to us!

Pass-the-permission-ticket vulnerability in UMA 2.0

Pass-the-permission-ticket vulnerability in UMA 2.0 =================================================== Am I impacted? -------------- You are probably not impacted if the UMA clients and the auhorization server only communicate with a list of known UMA resource servers. You are probably impacted in the following cases: * the UMA client is able to start flows with any UMA resource server. * the authorization server supports open dynamic registration of clients, without any pre-registration process or requirements for the client. In this case, you probably can't be sure that all your clients use the same list of trusted resource servers. Overview ------- In UMA 2.0, a malicious resource server (or a malicious server acting as a UMA resource server) can obtain a requesting party token (RPT) intended for another UMA resource server from a UMA client by passing a permission ticket obtained from the target resource server to the UMA client. This can compromise the privacy (confidentiality) and integrity of UMA protected resources. A malicious UMA resource server RS1, can trick a UMA client application into providing it a access token (RPT) which is actually intended for another UMA resource server RS2 (target resource server) by sending to the client application a permission ticket obtained from the target resource server. Unless the RPT is sender-constrained, the malicious resource server can then use this access token on the target resource server and act on the user's behalf. In order to that, when the UMA client application makes a request to the malicious resource server, 1. Instead of sending a RPT it would have obtained from the authorization server, the malicious resource server obtains it from the target resource server by making a request to the target resource server (acting as a UMA client) and sends this RPT to the client application. Instead of requiring permissions for the resources on the malicious resource server RS1, this permission ticket is for resources on the target resource server RS2. 2. If the UMA flow completes, the client application obtains an access token (RPT) associated with permissions on the target resource server but sends it to the malicious resource server. 3. When the malicious resource server receives this RPT, it can use it on the target resource server and can access the protected resources on behalf of the user. The malicious resource server does not even have to be registered as resource server on the authorization server as long as the client can be tricked into using it as a UMA resource server. Details ------- The client application makes a request to the malicious resource server RS1 (eg. POST https://rs1/foo): GET /foo HTTP/1.1 Host: rs1 ... The malicious server makes a request on the target resource server RS2 without RPT (eg. POST https://rs2/bar) in order to obtain a permission ticket for resources on RS2: POST /bar HTTP/1.1 Host: rs2 ... The target resource server RS2 requests a permission ticket from the authorization server: POST /perm HTTP/1.1 Host: as Content-Type: application/json Authorization: Bearer {PAT_OF_THE_RESOURCE_OWNER_ON_THE_TARGET_RESOURCE_SERVER} ... [ { "resource_id": "RID-XXXX", "resource_scopes": ["write"] } ] HTTP/1.1 201 Created Content-Type: application/json ... {"ticket":"PT-XXXX"} This permission ticket is associated with: * one or more required resources (on the target resource server) identified by resource_id (eg. "RID-XXXX"); * associated scopes for each resource (eg. ["write"]). The target resource server sends the permission ticket to the malicious resource server which forwards it to the client application: HTTP/1.1 401 Unauthorized WWW-Authenticate: UMA realm="...",\n\ as_uri="https://as",\n\ ticket="PT-XXXX" ... The client application completes the UMA grant and obtains a RPT for resources on RS2: POST /token HTTP/1.1 Host: as Authorization: {CLIENT_CREDENTIALS} Content-Type: application/x-www-form-urlencoded ... grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket &ticket=PT-XXXX &... HTTP/1.1 200 OK Content-Type: application/json ... { "access_token":"RPT-XXXX", "token_type":"Bearer" } The client repeats the request to the malicious server RS1 with the RPT (actually intended for the target resource server RS2): POST /foo HTTP/1.1 Host: rs1 Authorization: Bearer RPT-XXXX ... The malicious server now has a RPT for the target resource server and can make requests on the target resource(s) on behalf of the user: POST /bar HTTP/1.1 Host: rs2 Authorization: Bearer RPT-XXXX ... RS2 checks that the RPT is associated with the correct permissions and accepts the request. Mitigations ----------- The following mitigations could be used: * Allow-listing resource servers * Detecting of the phishing attempt before initiating the UMA flow * Detecting of the phishing attempt during the consent verification The following fixes of the protocol could be used: * Using sender-constrained RPTs (with DPoP or mTLS) * Extending the UMA flow to declare the resource server URIs in the messages Allow-listing resource servers ------------------------------ The client application could restrict its interactions with a list of known trusted resource servers (allow-list). Limitations: * Does not protect against compromised resource servers. * Does not work in a loosely-coupled/federated scenario where the clients applications and resource servers may be dynamically registered on the authorization server. Detecting of the phishing attempt before initiating the UMA flow ---------------------------------------------------------------- In the fake resource server case, the user is tricked into using the fake resource server. The user could detect this phishing attempt before initiating the UMA flow. Limitations: * Does not protect against compromised resource servers. * Only protects against phishing attacks. Des not protect against attack on the client itself. * Detecting this attack may be difficult, especially when the requesting party is not the resource owner and when the resource server may be dynamically registered on the authorization server. For example, a user may receive a legitimate invitation from another person to access a UMA protected resource located on a resource server hosted on another domain which would require authentication on the authorization server. Detecting of the phishing attempt during the consent verification ----------------------------------------------------------------- The user may be able to detect the attack during the interactive claims-gathering if the content of the authorization request is clearly indicated as part of the consent validation. The consent should clearly indicate: * the requested resources and resource scopes; * the identity of the associated resource server. Limitations: * In many cases, if would be difficult for the user to detect the attack based on this information. * Even if the authorization server checks the user consent, consent would have to be checked for all UMA authorization requests. If consent is remembered, the consent verification might be skipped during the attack and the user would not have the opportunity to detect the attack: remembering consent for the (RqP, client, resource, scope) tuple does not protect against this attack. Mitigations using sender-constrained RPTs ----------------------------------------- Sender-constrained access tokens (TLS-bound access tokens or DPoP access tokens) could be used in the UMA flow in order to mitigate the pass-the-permission-ticket vulnerability. As DPoP access tokens are easier to deploy, this solution should probably be prioritized over TLS-bound access tokens. Limitations: * Sender-constrained tokens must be supported by the client, by the authorization server and by the target resource server. * TLS-bound access tokens rely on mTLS which might be cumbersome to support. Mitigation by declaring the resource server URI ----------------------------------------------- The UMA protocol could be extended to exchange information about the URI of the resource server. This information could then be used to detect the pass-the-permission-ticket attack. Impact for the HEART Profile for UMA ------------------------------------ The HEART profile for UMA 2.0 is a UMA profile for healthcare It requires the support for loosely-coupled applications with UMA 2.0 Federated Authorization, dynamic registration of clients and dynamic registration of resource servers. Clients applications may dynamically connect to arbitrary resource servers which would dynamically register on the authorization server. In this scenario, the attack where a client application its tricked into connecting into a malicious resource server is not unlikely.

 

Malicious authorization server vulnerability in UMA 2.0

Malicious authorization server vulnerability in UMA 2.0 ------------------------------------------------------- Am I impacted? -------------- You are probably not impacted if UMA clients only interact with known resource and authorization services. You might be impacted if the following are true: * the UMA client is able to start flows with any UMA resource server * the UMA client is able to start flows with any UMA authorization server * the authorization server supports open dynamic registration of clients, without any pre-registration process or requirements for the client. In this case, you probably can't be sure that the client isn't a malicious AS Overview -------- A malicious server acting as both a resource server (RS1) and an authorization server (AS1) may trick the requesting-party into giving a RPT for another resource server RS2. Scenario: 1. the malicious resource server RS1 is registered on the target authorization server AS2 as a UMA client; 2. the client application is tricked into making a request to the malicious resource server RS1; 3. RS1 makes a request on the target resource server RS2 and obtains a permission ticket PT-XXXX; 4. RS1 redirects the client to a fake authorization server AS1 under its control; 5. the client application registers itself on the fake authorization server AS1; 6. the client starts an interactive claims-gathering on the fake authorization server AS1 i.e., redirects the user to AS (eg. https://as1/claims_gathering?...) 7. AS1 redirects the requesting-party's user-agent to AS2 (eg. https://as2/claims_gathering?...); 8. the requesting-party consents thinking he is granting a request for accessing resources on RS1 intended for its client whereas he is granting a request for accessing resources on RS2 intended for RS1/AS1; 9. the real authorization server AS2 redirects the user the malicious authorization server AS1 with a new permission ticket; 10. the malicious authorization server AS1 exchanges this ticket for the RPT; 11. RS1/AS1 can now make requests on RS2 on the RqP's behalf. Requirements: * the client application must make a request on the malicious UMA resource server RS1; * the client application must be able to dynamically register on unknown UMA authorization servers as requested by the UMA resource server (or be registered on a UMA authorization server controlled by the attacker); * the malicious resource server RS1 must be able to register on the authorization server as a UMA client (or already be registered); * the real authorization server AS2 must accept using interactive claims-gathering only (without pushed claims). The same attack works as well if the original resource server RS1 is not malicious but is connected to a malicious (or compromised) authorization server AS1.

Related content