OAuth PKCE Use Case

[sldab]

OAuth 2.0 works by issuing a redirect to an identity provider (IdP) and getting back an access token (implicit flow) or an authorization code (authorization code flow) appended to the application URL when being redirected back.

Now, both Android and iOS allow to register regular URLs as deep links that will open in your app instead of the browser. An attack vector on OAuth is to register the OAuth authorization endpoint as a deep link in order to intercept authorization requests and grab the access token or authorization code.

RFC 7636 allows to mitigate this attack but makes the authorization stateful on client side. In short, this is how it works: The OAuth client application generates a random string (code verifier), computes its SHA 256 hash and requests an authorization code together with this hash (code challenge). When requesting the access token in a backchannel request, it sends the authorization code together with the plain code verifier string, so the IdP can verify the hash value received before. Attackers can't easily guess the code verifier even if they intercepted the authorization request.

However, the plain code verifier string needs to be stored in the application and survive a redirect. Using local storage is one option, but local storage write access does not work in Safari private mode. Yet cookies are kept for the duration of the private browsing session in all browsers.

IdPs in areas with high security standards like ours only accept public OAuth clients that support PKCE. I'd like to provide an Elm OAuth library with PKCE support, but I don't see how to do this without resorting to native code.