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

[Justin Richer <[e-mail]>]

> On Mar 6, 2015, at 5:31 PM, Sergey Beryozkin <[e-mail]> wrote:
> 
> 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…)

I mean not doing anything special with the OAuth grants: use the redirects that are already there, just do something special with the page you’re redirected to that will display the code/token to the user and instruct them to paste it into the client appropriately. It can even be a pretty static page, with a bit of javascript to pull off the return values.

So you could build it like this: the user starts off at some webpage that says “Authorize AppX” and clicks that. This redirects them to the authorization endpoint, just like normal. Note that this redirect will include the client ID and scopes and all that, just like normal. Then the user logs in, authorizes, and is redirected back to AppX’s redirect_uri, just like normal. This redirect URI will be on the same service that hosts the “start off” page, if you want, so you can even check the “state” value against a stored cookie or session for extra protection. That page pops off the code or token parameter and displays it to the user, telling them how to get it into the client. Once the code or token is in the client, it goes on its way.

This all works without changing OAuth at all, and the auth server and resource server can be completely off-the-shelf. You’re effectively splitting the client in half: there’s a web-based half that deals with the authorization redirect, and a native half that deals with the code/token swap and the protected API calls. You use a person to glue them together.

I’ve built this kind of thing before, and it works well until people fall apart moving the displayed code between the web page and the rest of the application. That’s why a lot of apps, where possible, have just gone to popping up a browser. Dick’s recommendation to look at settop boxes and other apps that *can’t* pop up a browser is a good recommendation.

 — Justin


> 
> Thanks, Sergey
> 
>> 
>>  — Justin
>> 
>>> On Mar 6, 2015, at 12:22 PM, Sergey Beryozkin <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>