On Tue, Apr 6, 2010 at 7:53 AM, David Recordon <record...@gmail.com> wrote:
> The web client flow was intended to require either a fragment or SSL > (or optionally both). > Even with SSL, referrer leaks seem to be a danger (I think https referrers are still sent). Are we worried about this? > > > 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
