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

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Tue, 02 March 2021 20:04 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
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 749533A0EC3 for <oauth@ietfa.amsl.com>; Tue, 2 Mar 2021 12:04:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com
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 OCzezxuCdzFi for <oauth@ietfa.amsl.com>; Tue, 2 Mar 2021 12:04:47 -0800 (PST)
Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B213A0EC1 for <oauth@ietf.org>; Tue, 2 Mar 2021 12:04:46 -0800 (PST)
Received: by mail-ua1-x929.google.com with SMTP id 62so7172158uar.13 for <oauth@ietf.org>; Tue, 02 Mar 2021 12:04:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8xfSkZj3SBGXb7sCQ4QdOhyZont39ZA/GIvLEIG0Pw0=; b=zLz3Iiru5/seTrTYYJ80Qr3FLVDgqpUn68Q8klx34YXuBP9Ux9MXyZtjGMoyW68WhB q/qtfdeNMGysm2tEhmGOuBVyft+bUmJU/UUmkArKXvoxJC3BjoZfv74hHRovLQLFVRr+ s0niH/Ji7B+dFnKq0Cbs2z8uJHskc20p0iGknS+iy43hFxk9/INj0hOd5WvlVHOxXlkz 04HiCh88agOrUbscnyGiALNxFzEQe551B38AxeQFvFlVvobA8JvBzMkPtkND9neEV2PK cn8lJF96WJbuiHcufqQPMjOSOV3SNolOHagURV6UfGmFXDWypTnpV2GypUv6U9XBLQTS uBSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8xfSkZj3SBGXb7sCQ4QdOhyZont39ZA/GIvLEIG0Pw0=; b=e6VuQ28MOfGEm/KFKNWM9cwzUgVU/d/m/2Z9M1gID7yzd4HhEQb3q+uYcdRBQ4+Rbl kJ1C0RnR7k/trFx/hbyYXVcNdAQa7CbHU7XA9Eebq0repw6w96oO6lRszF1+O3IQxLuc 4aQ6n4Lyz7iimWTNCouVugAHItgT9jIbZKjpUdZBfeGaj8n7mvxNVfOQTVY//QFpTCqe oUs3WnbW+UQUAPO8fsX4wWCpqYfaY6Druxb26luPtn5F8SBcvEDXi1/zC4nAoRi+MhRJ O1/+eLjnIv+X+F8Zgs01Mrfnfw+rCKmmqmgwMcxVBn5+Y1JkofBCH+GY5Ca99cV98Tb4 zXBg==
X-Gm-Message-State: AOAM531O55meay07w2rbmyAknZMSj8h1s4qNwazr3rZgSAUoz0K7n8AE 5UF5koqaMw78LGzCqQ9cXBXaabOeBcBlIQmSwqugNg==
X-Google-Smtp-Source: ABdhPJx+h9EYcsVGXQTLpNbbbMpng65OD+8QdeQsdT19vfpftrTuJDBNhsO0Y4FiK0X9Q1Z9nCxD2SGg1JAfVGpRmrw=
X-Received: by 2002:ab0:3819:: with SMTP id x25mr6426664uav.115.1614715483771; Tue, 02 Mar 2021 12:04:43 -0800 (PST)
MIME-Version: 1.0
References: <6105c6f6-d291-b80e-4596-9ff4f10b3b55@evertpot.com> <F8A8B2DB-8CC4-447B-97F4-73F7357C62FF@mit.edu>
In-Reply-To: <F8A8B2DB-8CC4-447B-97F4-73F7357C62FF@mit.edu>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Tue, 2 Mar 2021 21:04:32 +0100
Message-ID: <CA+iA6ui1D7PmAJNfGY69Fh70NsqJwMLoOrg7DNCgsiEvAS8JmQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Evert Pot <me@evertpot.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d2ee2d05bc933e86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RIJwWYg-VydCZxwZJbc23IjnCd8>
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 20:04:50 -0000

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 <jricher@mit.edu> 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.
>
> While it’s 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’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
>
> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu