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

Unclear to me if this is a perfect fit for the question, but wanted to
raise awareness of WebOTP [1] which is coming up with conventions for
verifying phone numbers (e.g. with SMS OTP formats [2]) and email addresses
(e.g. conventions over magic links).

LMK if that's of interest/relevance and I'd be happy to expand.

[1] https://web.dev/web-otp/
[2] https://github.com/WICG/sms-one-time-codes

On Tue, Mar 2, 2021 at 12:10 PM Evert Pot <me@evertpot.com> wrote:

> Thanks Neil & Hans,
>
> Our AS doesn't do jwt quite yet. It's in-house, but open source. We don't
> have rfc7523 yet, but this does sounds like a pretty great longer-term
> solution.
> We're a bit time constrained, so perhaps this feature just needs to be
> done as a one-off before we can do RFC7523 for real, later.
>
> Thank you!
>
> On 2021-03-02 3:05 p.m., Neil Madden wrote:
>
> One option is JWT Bearer grant with “jti” and replay prevention (
> https://tools.ietf.org/html/rfc7523#page-7
> <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 <me@evertpot.com> <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
>
> 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
> 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
>