Hi Justin,
Thanks for typing it all, appreciated... I guess the idea here is
basically introduce a little web app 'intermediary' that will act as if
it were a client except that it will show whatever it receives back from
AS to the user.
So we still have a common processing path at AS, as if it were a regular
authorization code flow. I think I got it...
Thanks for the advice - enjoy the weekends
Sergey
On 06/03/15 22:47, Justin Richer wrote:
On Mar 6, 2015, at 5:31 PM, Sergey Beryozkin <sberyoz...@gmail.com> 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 <sberyoz...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
