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

From: Evert Pot <[email-masked]>
Date: Tue, 2 Mar 2021 14:04:36 -0500

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

---

From: Justin Richer <[email-masked]>
Date: Tue, 2 Mar 2021 14:50:46 -0500

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 <[email-masked]> 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>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 2 Mar 2021 21:04:32 +0100

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-masked]> 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.
>
> 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
>
> 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.

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Neil Madden <[email-masked]>
Date: Tue, 2 Mar 2021 20:05:35 +0000

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 <[email-masked]> wrote:
> 
> 
> Dear list,
> 
> 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
> 

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Evert Pot <[email-masked]>
Date: Tue, 2 Mar 2021 15:10:01 -0500

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

---

From: Sam Goto <[email-masked]>
Date: Wed, 3 Mar 2021 13:14:47 -0800

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 <[email-masked]> 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.
> One option is JWT Bearer grant with “jti” and replay prevention (
> https://tools.ietf.org/html/rfc7523#page-7
> 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 <[email-masked]> <[email-masked]>
> wrote:
>
> 
>
> Dear list,
>

---

From: Warren Parad <[email-masked]>
Date: Wed, 3 Mar 2021 22:29:00 +0100

I just formed a strong opinion, so I apologize if this comes across as if I
know something in the area. I think the warning is key here:

And in reality the WebOTP verification of phone numbers is actually a work
around for establishing client access via the real AS which in this case
would be the phone number provider. The fact that then there is even a
standard being developed on top of the hack workaround which in itself is
known to be a security risk, is shocking.

Rather than coming up with this, I would rather the phone os developers
just write phone side AS plugins to support push notifications from
providers uniquely identifying the device, rather than the phone number.
That would avoid the need to have a number, provide a mechanism that works
when "online" but not connected to the provider (i.e. in a different
network), and allow all AS connect to the user without needing a custom 3rd
party app instead specifically for the AS (or a generic one that lacks good
UX) for every new app a user wants to enable MFA using their device.

Magic links are certainly better if they don't register the device, and in
the case device persistence isn't a requirement, then jwt bearer grant
certainly works a good solution, doesn't it. Even with phone numbers you
can still send the link and click on it, thus sidestepping the
justification in the document about, since the SMS is a full link:

> Then copying and pasting it to the form is cumbersome

I'm probably missing ten different important nuances here though.

- Warren

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.