One option is JWT Bearer grant with “jti” and replay prevention (https://tools.ietf.org/html/rfc7523#page-7 ) if your AS supports it. This is nice if some other component is generating the emails as it needs no coordination with the AS.
— Neil > On 2 Mar 2021, at 19:04, Evert Pot <m...@evertpot.com> wrote: > > > Dear list, > > We have a requirement to let users log in to an application via a code sent > by email. > This code needs to be exchanged for an access/refresh token pair, and should > only work once. > > The access/refresh token scope would give limited access to the application. > Since we already use the authorization_code flow for other (more sensitive) > parts of the application, I would like to re-use the OAuth2 framework for > parts of this. > > It doesn't sit right with me to overload the 'code' in authorization_code, so > I was considering introducing a new custom grant_type for our application, > specific for this purpose. > It seems that grant_type in the 'token' endpoint would support extension in > this manner, by using a uri such as https://vendor.example/email-token > > I'm comfortable implementing this, but curious: > > Is there already some prior art that I'm not aware of? I'd rather not do a > custom grant_type if there's something standard I could do. > Are there any major pitfalls associated with this? > Evert > > _______________________________________________ > 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
