From nobody Tue Mar 2 11:50:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EAB3A0E71 for ; Tue, 2 Mar 2021 11:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKqzBW9mqM8E for ; Tue, 2 Mar 2021 11:50:51 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016EF3A0E6E for ; Tue, 2 Mar 2021 11:50:50 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 122JokX5020970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Mar 2021 14:50:46 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_45E183C9-841C-46EA-923B-5D96FD172F04" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 2 Mar 2021 14:50:46 -0500 In-Reply-To: <6105c6f6-d291-b80e-4596-9ff4f10b3b55@evertpot.com> Cc: "oauth@ietf.org" To: Evert Pot References: <6105c6f6-d291-b80e-4596-9ff4f10b3b55@evertpot.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] One-time token login X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2021 19:50:53 -0000 --Apple-Mail=_45E183C9-841C-46EA-923B-5D96FD172F04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=20 While it=E2=80=99s 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=E2=80=99ve 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. =E2=80=94 Justin > On Mar 2, 2021, at 2:04 PM, Evert Pot wrote: >=20 > Dear list, >=20 > 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. >=20 > 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. >=20 > 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: >=20 > 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 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_45E183C9-841C-46EA-923B-5D96FD172F04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s 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=E2=80=99ve 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.

 =E2=80=94 = Justin

On Mar 2, 2021, at 2:04 PM, Evert Pot <me@evertpot.com> = wrote:

=20

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-t= oken

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

= --Apple-Mail=_45E183C9-841C-46EA-923B-5D96FD172F04--