[OAUTH-WG] Re: PKCE RFC 7636 and registered URLs

[David Waite <[e-mail]>]

> On Oct 1, 2024, at 3:44 AM, [e-mail] wrote:
> 
> Hi,
>  
> is this sentence in the introduction of RFC 7636 <https://datatracker.ietf.org/doc/html/rfc7636> still true?
> “The Redirection Endpoint URI in this case typically uses a custom URI
>    scheme.”

I would say this is still true in the market, although it does not constitute advice or best practices.

The mechanism to support terminating an ASWebAuthenticationSession via host-and-path rather than via custom scheme was added in 17.4 (March). I believe the tab created by this API does not dispatch Custom URI nor universal links to the OS for resolution, so there is not the same risk profile from malicious apps.

On the Android side, play services support for Lollipop (the last release without app link support) ended in July.  I don’t think you have the same expectations around protections from URI scheme hijacking with custom tabs, however.

I would expect on both platforms, client best practice would be to support both Custom URI and claimed https URI, with apps choosing one or the other dependent on the system they are running on. If I were to look at metrics there however, I would expect both platforms to drop below 10% usage of the Custom URI endpoint over the next 12 months - Android is probably close if not there already.

> Is the word “typically” still true nine years after rfc7636 was written?

I don’t personally think it matters. The description of using Custom URI scheme in the introduction doesn’t serve as a recommendation to do so, but rather to illustrate the potential attacks that the document is attempting to alleviate.  It is there to justify need.

PKCE usage has increased with draft-ietf-oauth-security-topics - it is now considered to be appropriate for an AS to require for all clients and not just certain native clients. I would expect an update/replacement for 7636 to emphasize appropriateness for these other applications.

>  
> I suggest removing the word “typically” in the introduction and adding a security section that recommends registering the mobile app for an URL.
>  
> 7.6 Registering the mobile app for an URL
> Major operating systems and app store management systems allow the registration of an URL to a mobile app.
> With an URL registered to the mobile app an attacker cannot register their malicious app for the same URL as the mobile app.
> It is RECOMMENDED that the developer of the mobile app binds the app to an URL.

I think this would instead belong in a document aiming to update/obsolete 8252 - but I believe that document already has plenty of text around claimed HTTP URI and Custom URI schemes.

> Also, I am wondering why this mechanism is not mentioned in https://datatracker.ietf.org/doc/draft-parecki-oauth-first-party-apps/

First party apps is primarily proposed as a way to do authentication with native UI rather than through an external user-agent. So think of it as a third option for a percentage of clients which are trusted by the AS.

-DW