No, it doesn’t mention this attack. The issue is that if the redirect_uri is not strongly bound to a legitimate client then a malicious app on the user’s device can initiate an OAuth flow and impersonate the legitimate client and then intercept the response by claiming to handle the redirect_uri.
We thought this was solved by using claimed https redirect_uris (Universal Links on iOS, AppLinks on Android), as these require the webserver to publish a document explicitly granting permission for a particular app to claim part of its https address space. But it turns out that Android has a hole in this because it allows any app to claim to be a web browser and so handle all URIs. (I thought this attack was discussed in the security topics bcp, but I can’t see it). The 2.1 draft currently requires (MUST) ASes to support private-use URL schemes, which makes this problem much worse. IMO private-use URL schemes are un-securable and shouldn’t be encouraged let alone mandated. — Neil > On 17 Mar 2021, at 05:17, Om <omkarkh...@gmail.com> wrote: > > If I read this correctly, > https://tools.ietf.org/html/draft-ietf-oauth-v2-1-01#section-10 the 2.1 draft > already addresses this under best practices. > >>> On Mon, Mar 15, 2021 at 3:31 PM Neil Madden <neil.mad...@forgerock.com> >>> wrote: >> I want to come back to this topic as a new thread. >> >> As I understand things, the difference on Android is that any app can claim >> to be a generic web browser and so claim to handle all URIs. Whereas on iOS >> only specifically vetted apps can claim to be web browsers. Is that correct? >> >> If so, this does seem like a quite large hole in security of OAuth on >> Android. Should we be considering a new draft recommending alternative >> measures (such as attestation) on Android? Presumably the same issue is also >> true on most desktop OS? >> >> — Neil >> >>> On 23 Feb 2021, at 15:20, George Fletcher <gffle...@aol.com> wrote: >>> >>> Unfortunately, in the mobile app world this isn't sufficient. On iOS using >>> Universal Links will bind the https redirect_url to your app in a secure >>> way but it doesn't work the same way on Android with App Links. There is >>> still a problem with "mobile app impersonation". If you have an app that >>> you want to ensure is "your" app then the most secure way is to look at >>> "app attestation". This is however, way off topic for this thread :) >>> >>>>> On 2/14/21 9:28 AM, Neil Madden wrote: >>>> Public clients are implicitly authenticated by their ownership of the >>>> registered redirect_uri. This why it’s important to use a redirect_uri for >>>> which ownership can be reasonably established, such as HTTPS endpoints >>>> with exact URI matching. >>>> >>>> There are more things that can go wrong with that (see the security BCP), >>>> but it can be made reasonably secure. >>>> >>>> — Neil -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
