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

Justin Richer <jricher@mit.edu> Fri, 06 March 2015 18:28 UTC

Return-Path: <jricher@mit.edu>
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 C4D061A1B72 for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2015 10:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8qOs556ZmsjL for <oauth@ietfa.amsl.com>; Fri, 6 Mar 2015 10:28:57 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1C01A1B2D for <oauth@ietf.org>; Fri, 6 Mar 2015 10:28:57 -0800 (PST)
X-AuditID: 12074425-f79846d0000054e1-d6-54f9f1e7fdee
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.72.21729.7E1F9F45; Fri, 6 Mar 2015 13:28:56 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t26IStPd013481; Fri, 6 Mar 2015 13:28:55 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t26ISrEe008355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Mar 2015 13:28:54 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_63D7876E-AF8D-41DC-A58A-A2AF709B5576"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b5
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <54F9E246.70901@gmail.com>
Date: Fri, 6 Mar 2015 13:28:52 -0500
Message-Id: <52A4984A-5ACE-472D-986D-54012EB620C2@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>
To: Sergey Beryozkin <sberyozkin@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA01SW0hTYRznO7udTY8d5+1zOUZDk5SZSQ928VL54KOEJfRgnrmvbbRNOWcT Z5JWRmYa1oORNHJeujhhY6Q1hRzDly0CfZDMSlQCayZqF9FQ6RzP1N5+3/93+f//fH9cIPeL FLjRYkW0hTKpxTKhXJqQqfm2ulGa7VwAucGlsDh3u6+gECv2dX6RFPf2bmAl2CXZaR0yGWsQ fTS/QmYYabotqe5X1a65bwgawXZyC8BxSB6H/pC2BUhZmAjHZ9ziFiDD5WQPBj1/u0X8wwPg K3dfhJnF4PDNdxLOEkeegX6vR8hhgsyGjtBvjBMJyIcAvgiEBHyuAs5+GgAcFpNp8NFAE8Zh KZkOZ7Y2d+pCMhX6XVw7nDWnwzvBIj7zJBz50wT4xj4MLrVt7WTGk5lwYnFawq+ggq1efTuI 7fxvjM7/x+AIAWt55lyM4CNw9N5zIY9V8PXSk0j9BOx5PBWp58Hp+10Yj/PhfEe3qAvg/UCp M9dpzJTRxKBKDVNJWSyI1uRmmY3WLKSzeQH3OZKitDegPaAOABIH6miiWbFRKhdRNYzdHADJ OKZOILTLbClGW6WzGyjGcJm2mRATAKlsr3mPaxwohJYqC1LHEw/mWB2ho+x1iK7alR3Eheok wrseUyon9ZQVXUWoGtG7bAqOqyHRsMIaY2mkR7VXjCbrPo3h0gCAeDQbPsVpCKaaMjNGPc+H wCFFEvGLI0iOMNgse97dwwuDJHatOGKOU0WzZ7nnDrPBGBuckbjOBVupfUrRCFTajoKcnLFz g2gl/XB9u/Ju2Wh5cMvqgnkX+s6WwOHr43LxaPBnpbxNAibPO9vWHRXXbMsfX9YvxH5vHdEX fa1PihrabBB0a+bQxDLRc2DN1/x50O0o+6Esv2gPfvCsntp+W9halvb+6eSk81YoyuF2OIYa UnzK8FhClkugFjIG6liGgGaof6Ft8JtTAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/GiYp2WZ50fSoKIoA8WqQBEfWgiw>
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 18:29:00 -0000

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.

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.

 — 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