When the requesting party is redirected to the authorization server for interactive claims gathering, a man in the middle/man in the browser can manipulate messages, impacting the
claims_redirect_uri parameter (in what is called the Mix-Up attack in the case of a OAuth security analysis) and potentially more elements of the front-channel messages involved. The
claims_redirect_uri parameter is similar to the OAuth
redirect_uri parameter and some attacks may be able to be mitigated through approaches described in the OAuth Security Topics Internet-Draft (at revision 04 at the time of writing), Section 4.4. If the syntactic mitigation approach described is taken, the authorization server's redirection response back to the client would need to be extended with additional parameters as described in the OAuth 2.0 Mix-Up Mitigation Internet-Draft (at revision 01 at the time of writing). If the client-side mitigation approach described is taken, the client would have to perform a number of coordinating and tracking actions in addition to choosing authorization server-specific URLs. The client could additionally use the
state parameter and choose a specific type of value that carries enough application state to enable it to match the value with its callbackthere are several possible attacks identified by the OAuth 2.0 Security Best Current Practice. The OAuth 2.0 authorization code flow is substantially similar to UMA interactive claims gathering: the `claims_redirect_uri` parameter is similar to the OAuth `redirect_uri` parameter, the incoming ticket is similar to OAuth scopes, and the returned ticket is similar to the OAuth authorization code; both flows require a client_id and recommend a state parameter. Therefore, these attacks can be mitigated through the countermeasures described in the OAuth 2.0 Security Best Current Practice. Two such attacks are Cross Site Request Forgery (Section 4.1), recommending application of PKCE, and the Mix-Up attack (Section 4.4), which has several possible mitigations.
One consideration specific to UMA is the possibility for the client to repeatedly invoke interactive claims gathering redirection before use of the token endpoint. This is possible since each ICG cycle results in a new UMA ticket to be issued to the client. This possibility requires additional security analysis and profiling of PKCE to ensure it still effectively provides the desired client authentication outcome. Another potential mechanism to mitigate these attacks is the use of client DPOP. Instead of a PKCE code challenge/verifier, the client is registered with a public key, possibly through DCR, and dynamic client authentication is the required at the token endpoint. Another direct resolution is for an AS profile to explicitly require a call to the token endpoint with the UMA ticket received through ICG redirection. This effectively ensures the PKCE flow is performed as designed.