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

Justin Richer <jricher@mit.edu> Tue, 02 March 2021 19:50 UTC

Return-Path: <jricher@mit.edu>
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 <oauth@ietfa.amsl.com>; 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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; 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 <jricher@mit.edu>
Message-Id: <F8A8B2DB-8CC4-447B-97F4-73F7357C62FF@mit.edu>
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" <oauth@ietf.org>
To: Evert Pot <me@evertpot.com>
References: <6105c6f6-d291-b80e-4596-9ff4f10b3b55@evertpot.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7pr7vOnFlCvO1cCGZgiPO4_NjeU>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 19:50:53 -0000

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