I've created a pull request to update this section here: https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/82/files
Aaron On Wed, Jun 14, 2023 at 6:47 AM Aaron Parecki <aa...@parecki.com> wrote: > Hi Alex, > > I see what you mean, in Section 4.4.1 with the implicit flow, the sequence > ends with the redirect back to the client from H-AS with the access token. > Steps 5 and 6 don't happen with the implicit flow, so "works as above" > isn't descriptive enough. > > The paper describes a slightly different way the attacker gets the access > token, which is after the client attempts to use the access token from H-AS > to retrieve resources from A-RS or retrieve user info from A-AS. I believe > the description of the implicit variant in the Security BCP should be > updated to make this more clear. > > Thanks! > > Aaron > > > > On Wed, Jun 14, 2023 at 6:23 AM Alexander Rademann < > alexander.radem...@web.de> wrote: > >> >> >> *Hello, everyone!Section 4.4.1 of the BCP >> <https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-23.html#section-4.4.1> >> draft lists several variants of mix-up attacks; the description of the >> Implicit grant variant reads as follows: "In the implicit grant, the >> attacker receives an access token instead of the code; the rest of the >> attack works as above."Given the attack description in that section, it is >> not clear to me why an attacker would receive the access token and which >> part the "rest of the attack" refers to. When the Implicit grant is used, >> H-AS sends the access token (via redirect) to the user agent, which >> extracts it and sends it to the client. However, the client does not send >> the access token to A-AS, does it? (I hope that I didn’t overlook anything >> in that section.)* >> >> >> >> *I also checked the referenced paper <https://arxiv.org/abs/1601.01229>; >> there, the authors assume that the access token is sent to the >> authorization server under the control of the attacker (or, using their >> terminology, identity provider) to access some resource. [Appendix B, p. >> 31ff] Perhaps this (or some similar) assumption should be added to the >> description of this variant?I'm sorry if I missed anything or if this has >> already been addressed before, I'm new to this mailing list and did not >> find anything in the archives.Kind regardsAlex* >> _______________________________________________ >> 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
