We're starting down the path of working with the 2.0 draft, and we've got some admin web applications we want to protect. Part of what we're trying to do is frame the problem correctly, so I'd appreciate any corrections where I've jumped the track from the 2.0 ideas.
We'd like to start out being as true to the spec as we can. (Sorry if I'm being a little fussy here ;) but with 1.0, we found that we're happier when we used the spec as stated rather than getting creative.) Specifically, we have a number of admin UI web pages we'll serve with SSL. We'll do authentication through a centralized Authorization service. So far, that fits nicely with the web server flow. It also fits nicely with the "username and password" flow, if we add a back channel for user authentication. But the trouble comes transmitting the access tokens from a "dumb" web page. + After we go through the process of getting an access token, we'd like to set that as a cookie and pass it that way, rather than as an Authorization header. But I don't see a provision for that in the spec. + Alternately, a URL rewriting scheme would allow us to provide a query string parameter, as allowed in the spec. But that is much less simple than just using a cookie. + Is it even if fair to consider the browser a client? + Is this even a fair use of OAuth 2? Best Regards, Rob -- You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oa...@googlegroups.com. To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth?hl=en.
