Would it be fair to characterize this attack vector as a mix-up attack where the malicious app is essentially an Attacker AS?
In the Desktop OS category, responding with the *issuer* in the authorization response ( https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00) returned to the user's browser via the one that presumably user started the flow with. But on Android apps can directly decide intercept the authorization response thus invalidating the protection mechanism instituted by the draft? I do agree that hypothetically there could be a malicious program installed in the Desktop OS environment that could perpetrate this attack. However, without thinking too much about it, I'm biased to believe existing TLS and browser security mechanisms are sufficient with the addition of the *issuer *included in the response. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Mar 17, 2021 at 9:15 AM Neil Madden <neil.mad...@forgerock.com> wrote: > Right, but PKCE doesn’t stop an attack when the malicious app initiates > the authorization flow. > > On 17 Mar 2021, at 08:04, SOMMER, DOMINIK <dominik.som...@milesandmore.com> > wrote: > > > > I’d throw in PKCE as a means of assuring that the client who made the user > follow the auth flow in the first place, is apparently the only one able to > “redeem” the auth code returned to the redirect_uri. > > > > > > *Von:* OAuth <oauth-boun...@ietf.org> *Im Auftrag von *Om > *Gesendet:* Mittwoch, 17. März 2021 06:17 > *An:* Neil Madden <neil.mad...@forgerock.com> > *Cc:* Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org>; > oauth <oauth@ietf.org>; Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > *Betreff:* Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token > Mediating and session Information Backend For Frontend (TMI BFF)] > > > > 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 > > > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.slept...@gmail.com> > <stoycho.slept...@gmail.com> wrote: > > > > > > I would like to add my reasons about the "Why are developers creating BFF for > their frontends to communicate with an AS", > > with the objective to verify if they are valid. > > > > I need the client app. to be authenticated at the AS (to determine if it is a > first-party app., for example). > > If we decide to implement our client as a frontend SPA , then we have no > other option except through a BFF, as PKCE does not help for authentication. > > > > Or is it considered a bad practice to do that? > > > > Regards, > > Stoycho. > > > Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, > Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt > am Main HRB 116409 > Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > - Regards, > Omkar Khair > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
