On Wed, Apr 21, 2010 at 10:13 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote:
> Am 21.04.2010 17:31, schrieb Evan Gilbert: > > > > On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Am 21.04.2010 02:45, schrieb Evan Gilbert: >> >> >> >> On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt < >> tors...@lodderstedt.net> wrote: >> >>> Hi all, >>> >>> I would like to propose an additional variant of the Web Server Flow w/o >>> the need for direct communication between client and authorization server in >>> order to obtain authorized access/refresh tokens. Instead access and refresh >>> tokens should directly be send back with the redirect to the client as it is >>> the case in the User-Agent Flow. >>> >> >> Question (and sorry if I'm being dense) - what is the delta between Web >> Server flow + verification_code=false and User-Agent flow? >> >> >> This is not a dense question :-) >> >> The User Agent Flow adds the data as URL fragment which is not passed to >> the web server (as far as I understand). My proposal adds this data as URL >> query parameters, which are passed to the web server by the user agent. >> > > At one point we had tokens in query string for the User-Agent flow, but > there were concerns about the security side. Query parameters are much more > likely to leak in logs and in referrers. > > It's not a lot of work to support this functionality with the existing > User-Agent flow using a boilerplate response page. Page would: > 1. Grab fragment > 2. Make XMLHttpRequest with access token & refresh token to server, or POST > a form > 3. Redirect to destination page. > > Would this work? > > > I think this would work but is IMHO somehow cumbersome and requires two > requests to the service. > I agree it's cumbersome. Hopefully the security folks can respond with the pros/cons of tokens in the query parameters. > Alternatively, the authorization server could directly respond with a HTML > page containing a HTML form element with all response data. This form could > automatically be submited to the service using JavaScript. This would be > similar to OpenIds "HTML FORM Redirection". > This is a good idea. Might make sense to support as a best practice - the form can be static and it's fairly easy for any client to host it. We recently had a similar discussion on the Native Application flow on the OAuth WG thread - decided that we could implement the Native Flow as the Web Server flow + a simple HTML web page. And the web page wouldn't be directly part of the spec, but a separately documented best practice. (note - I don't have strong opinions on this - mostly discussing options) > regards, > Torsten. >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
