[OAUTH-WG] Returning tokens directly to a human user

Sergey Beryozkin <sberyozkin@gmail.com> Fri, 06 March 2015 17:22 UTC

Return-Path: <sberyozkin@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 68AFA1A00DC for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2015 09:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ah0mvwyl4QZB for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2015 09:22:30 -0800 (PST)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 D17FE1A0072 for <oauth@ietf.org>; Fri, 6 Mar 2015 09:22:29 -0800 (PST)
Received: by wibbs8 with SMTP id bs8so5195642wib.0 for <oauth@ietf.org>; Fri, 06 Mar 2015 09:22:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=IaxjTR/hWOSWsAlPKK1Jr2DgN5EZbYiklceJ+AQhGCc=; b=sZAfwSECzbp9AoZ8nWWw+KrqqhkHqzrQE1zmskFxsYEObVAfws9JICsYBY30pwchqa FVJL2a9gBsSbGHQQ7AJ9jS4upubDHAW6jBtpA1Jv+DqSdRwvoEJWB2iVv8zZXuiDaoM/ 80isQrYk0ZctZVz5IcYBXb77qzJ2x3eUxY0V9g8OjjVo694R8cSV35mGS2/IUIXAdNqi /jKankh474jIVT49gN2I/DAiYiCx+bmSKejCTHumHBEeN5QUDlbUTGgQSHOjej3GBshp AwpjQo8rpnQmgG3SudG7D+oAcIZpR3VsKMlmsAAPCAYEzCj8WjBNhq6kvehRbAGtiBe+ 6p0w==
X-Received: by with SMTP id o19mr13908549wiw.90.1425662548713; Fri, 06 Mar 2015 09:22:28 -0800 (PST)
Received: from [] ([]) by mx.google.com with ESMTPSA id e18sm15800441wjz.27.2015. for <oauth@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 09:22:27 -0800 (PST)
Message-ID: <54F9E246.70901@gmail.com>
Date: Fri, 06 Mar 2015 17:22:14 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <54F59359.5020601@gmx.net> <2A7D9B45-2459-4558-8356-CAB1029D113D@MIT.EDU> <4E1F6AAD24975D4BA5B1680429673943A2E78D9F@TK5EX14MBXC292.redmond.corp.microsoft.com>, <54F7C2B7.7090304@mit.edu> <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943A2E79640@TK5EX14MBXC292.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/qo_lCvb5B_WVtvjUaL7HmAPiUGg>
Subject: [OAUTH-WG] Returning tokens directly to a human user
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 06 Mar 2015 17:22:34 -0000

Hi All,

We might have a requirement to support a case where AS returns an access 
token directly to a human user, with the user subsequently configuring a 
confidential client with this token. The actual client is not capable of 
supporting a (more dynamic) code flow at this stage.

So it is nearly like an implicit code flow except that the user is asked 
upfront which clients can get the tokens allocated and the token is 
returned in the HTML response without redirecting and placing the token 
in a fragment.

Apparently a number of big providers do just that, let users allocate 
tokens for some clients with the users expected to copy the tokens into 
the confidential clients afterwards.

I'd like to ask, it is a reasonable approach, to have tokens transferred 
manually into the confidential client ?

Would it be more appropriate for a user to request a code and then copy 
it to the confidential client and expect it to get the tokens itself. I 
guess the problem here may be a code is short lived, but so is a typical 
access token - but the latter can be supported by a refresh one.

Another question: does it even qualify as an OAuth2 grant for token 
exchange, the process of a user pre-authorizing a client and getting not 
a code but tokens back ? I guess it does, so how a grant like this one 
would typically be called ? We'd have no problems with assigning some 
custom name to such a grant but curious how others approach it...

Thanks, Sergey