The web client flow was intended to require either a fragment or SSL (or optionally both).
On Tue, Apr 6, 2010 at 7:04 AM, Evan Gilbert <uid...@google.com> wrote: > > > On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> >> Hi Evan, >> >> On 4/5/10 4:28 PM, "Evan Gilbert" <uid...@google.com> wrote: >> >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow >> > In both flows, the authorization server should be able redirect back to >> > the >> > callback URI without interacting directly with the resource owner if >> > access >> > has already been approved. This is not ruled out in the current >> > language but >> > it could be made cleaner. >> > >> > Suggested rewording - change >> > >> > "After receiving an authorization decision from the resource owner, the >> > server >> > redirects the resource owner to the callback URI." >> > >> > to >> > >> > "If the client is already approved or denied for access to the protected >> > resource, the authorization service MAY redirect the resource owner to >> > the >> > callback URI immediately. If not, the authorization service SHOULD ask >> > the >> > resource owner for an authorization decision and after receiving the >> > decision redirect the resource owner to the callback URI." >> >> I opted for a simpler change: >> >> 'After receiving (or establishing via other means) an authorization >> decision' > > Sounds great > >> >> > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow >> > We should have an OPTIONAL username parameter: >> > username >> > The resource owner's username. The authorization server MUST only send >> > back >> > refresh tokens or access tokens for this user. >> > >> > This is useful for clients where a user is already logged into a 3rd >> > party web >> > site with a specific account, and the client wants the authorization to >> > match >> > the specific user. >> >> I think introducing the concept of user identity is more complex than just >> a >> username parameter. I agree that it can be useful but we need a more >> detailed discussion about this before we add it. > > I agree issues around user identity are complex. > Would it help to spin up a separate discussion thread on this one issue? >> >> > 2.4.2 Web Client Flow >> > Sending an access token as a query parameter is dangerous from a >> > security >> > perspective - these tokens are leaked via referrers and server logs. In >> > previous WRAP discussions, it was felt that we should have a strong >> > recommendation to use the URL fragment. >> > >> > Suggested wording: >> > Client SHOULD send a callback URI with a query fragment, and >> > authorization >> > server MAY reject callback URLs without a fragment for security reasons. >> >> Why not require it? > > I made the assumption that someone had use cases that drove the examples in > the spec. > I would be OK with requiring it. >> >> EHL >> > > > _______________________________________________ > 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
