IMHO this use case is about proving the ownership of an e-mail address to authenticate the user to obtain an access token. The authorization code is not really suitable because it is supposed to be short lived and (more or less by induction) supposed to be associated with an account at the AS. I'd suggest to either: a) maintain an account for the user that he can sign in to with the link received on his e-mail address, and subsequently start a regular authorization code flow, or b) not maintain such a persistent account but directly use a JWT as an authorization grant towards the token endpoint as described in https://tools.ietf.org/html/rfc7523#section-2.1
Hans. On Tue, Mar 2, 2021 at 8:51 PM Justin Richer <[email protected]> wrote: > I agree that it seems strange to use the authorization code in such a > manner, though I can see how it could work on a technical basis. > > While it’s not an exact match, you might want to look at the Device Grant: > > https://tools.ietf.org/html/rfc8628 > > Here you issue a user-typable code that gets entered into the client app. > While the canonical use for this is things like set top boxes, I’ve seen it > used to onboard secondary devices using an out-of-band communication > mechanism, which seems like it might fit here better. > > Ultimately, OAuth is most comfortable living around web browsers, so any > time you go outside of that space things start to look a little funny. > > — Justin > > On Mar 2, 2021, at 2:04 PM, Evert Pot <[email protected]> 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: > > 1. 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. > 2. Are there any major pitfalls associated with this? > > Evert > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > -- [email protected] ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
