I don't see why would you use the user-agent flow with a native application? Maybe the spec should suggest only the web server flow. The device flow would also work, but that's not part of the core spec.
Marius On Wed, Sep 15, 2010 at 2:47 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > I'm wondering whether it makes sense to allow for the issuance of refresh > tokens by the user-agent flow. > > Background of my considerations is the development of applications on mobile > devices (apps :-)). The draft suggests to either use the web server or the > user agent flow for the integration of such applications with an OAuth > authorization server. For sake of user experience, I would expect mobile > applications to use refresh tokens instead of sending the user through the > authorization on every application start. I also would assume that the > mobile client does not use a client secret because it cannot really protect > it from recovery. Instead, token theft could be encountered by replacing > refresh tokens with every request to the tokens endpoint. > > This scenario is feasable with the web server flow but not with the > user-agent flow. This is because the later does only support the issuance of > access tokens. In previous discussions this has been motivated by the weaker > security (missing client authentication) of the user-agent flow. But as > pointed out above, the web server flow can (and will be) used w/o client > secret, too. > > So why don't we allow for the issuance of refresh tokens by the user-agent > flow? > > regards, > Torsten. > > > > _______________________________________________ > 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
