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 <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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
