Re: [OAUTH-WG] One-time token login

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 <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 <me@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 <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