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 <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
