> On Oct 1, 2024, at 3:44 AM, [email protected] 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
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
