Hi all,
Following the PKCE discussion last week here's some proposed changes to the UMA implementers guide[1]. The guide already has a section addressing "Security Considerations Regarding Interactive Claims Gathering Flows" [2]. The change below changes the focus from only the Mix-Up Attack, and more generally recommends application of any relevant countermeasures from the OAuth BCP document (including use of PKCE)
Cheers,
- Alec
Existing Text:
```
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 callback.
```
Proposed Text:
```
When the requesting party is redirected to the authorization server for interactive claims gathering, there are several possible attacks identified by the [OAuth 2.0 Security Best Current Practice](
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14). 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](
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14). 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.
```
Hi,
We’ve had some requests to add PKCE [1] to the interactive claims gathering flow [2], eg example for public clients. Technically, there is little challenge to directly apply the PKCE code challenge/verifier, with the assumption that the authorization code is equivalent to the uma ticket
Has anyone done this? Any additional considerations?
Thanks,
- Alec