If you are interested in how others have done a similar flow, you could look at how smart TVs supporting Netflix and Amazon are authorized.
On Fri, Mar 6, 2015 at 9:22 AM, 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
