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> 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_______________________________________________ > 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
