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

Sergey Beryozkin <sberyozkin@gmail.com> Fri, 06 March 2015 22:31 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E011A00A2 for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2015 14:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSQbjPyP9OVy for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2015 14:31:55 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 BFD681A1AA1 for <oauth@ietf.org>; Fri, 6 Mar 2015 14:31:54 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so6935625wib.2 for <oauth@ietf.org>; Fri, 06 Mar 2015 14:31:53 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PCbGLLWAg6vscG4ev4dKes8roTM1tFkJi+FQ6hSwjHc=; b=aMKk+nh/Z/ze8exbFVjrVaIyppEPfkyj+wr4XgKJqfiW8K4/Rd+XYL6fjsRbz0M9Ks SMsftHBfgICQHCoMtozKx4Zvz6GYKu+5pbOSkUHInnpj7vNdQ9t6Bb1P0JDWFTNJ6t5T 0//s4Anqyxe8RGrM9wcea3smefUZpYnkLikRt8w7Ts8i1KMeTivuaRVzMiH80hxI9d8i GjjrS/9R1mYzdn8ghob4kGvZ0AAGNq7Y0v3zSEIUtygQFvGifHEeJQ3KUCL0pXDAKpmS +v0MS1dkeSxJHQXbcvWKAj2juxhhgjvDeJj+9w3KVZZZsPVnvNGBngD1XfIveUXk6Bg7 g8eg==
X-Received: by 10.180.8.10 with SMTP id n10mr36550026wia.79.1425681113592; Fri, 06 Mar 2015 14:31:53 -0800 (PST)
Received: from [192.168.2.7] ([89.100.10.58]) by mx.google.com with ESMTPSA id w4sm4108009wib.19.2015.03.06.14.31.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 14:31:52 -0800 (PST)
Message-ID: <54FA2AD7.7000500@gmail.com>
Date: Fri, 06 Mar 2015 22:31:51 +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: Justin Richer <jricher@mit.edu>
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> <54F9E246.70901@gmail.com> <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu>
In-Reply-To: <52A4984A-5ACE-472D-986D-54012EB620C2@mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/_RsuyqqJFJAyBciestyTA4GRUbU>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [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 22:31:57 -0000

Hi
On 06/03/15 18:28, Justin Richer wrote:
> All you’re really doing here is having a more manual and less automated portion for part of the process. You’d want to do this using a registered redirect URI that hosts the HTML page, and then you’d need a control in the app itself where the user could interact.
>
> I would personally recommend using this approach to move an authorization code manually instead of moving an access token. Assuming your client can access the auth server directly (using the backchannel, no browser), you should be able to POST to the token endpoint and get the token directly without the user having to handle it. The reason being that auth codes are client-limited and much more time-limited, and their leakage doesn’t immediately lead to leakage of API access.
>
Right now this is what I'm considering, whether to restrict it to the 
client getting the tokens itself, with the inserted code, or indirectly, 
after the user does it. We already support the former for public 
clients, I guess in the latter case a token will also be linked to a 
client because a user will enter a client id when requesting a token.

Just not sure yet if a 3rd party client will be 'prepared' as you say to 
interact directly with AS, I guess it will be given that it is expected 
it should be able to refresh...


> We had a similar approach with a limited client back in the OAuth 1.0 days, where we had an HTML page that would print the oauth_verify code on the screen that the user would type into the application. These days, on most platforms, it’s much easier to register a custom URL handler or use another system service to get the code directly that this hack has all but disappeared, at least in my view.

Can you give me a favor and clarify a bit what you mean when referring 
to a registered URL handler ? A user signs in, requests a code or a 
token for a specific client, AS returns it to the user directly. I guess 
it can redirect the user to some other web application which is where 
the user will interact and get the code or token. What a registered URL 
handler can change in this process, make it more automated ? (I 
understand working with the code is better in general...)

Thanks, Sergey

>
>   — Justin
>
>> On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>