-1. It is a BAD security practice to pass credentials in URLs. Avoid it. Phil [email protected]
On 2011-03-10, at 10:07 AM, Richer, Justin P. wrote: > Ah, here we run into the classic argument of usability vs. security, in which > usability will win every single time in practice. If we don't define at least > a reasonable way to do this within the scope of OAuth, that's not going to > stop people from doing it. It's just going to make people do it in a million > different ways, each with their own unique problems that nobody's thought of. > At least this way, we can enable it and have a real discussion about the > security considerations. There are valid and valuable places where putting > credentials in the URL is a reasonable security tradeoff. Not everything > functions over the public internet as well, and the security considerations > are different in these other environments. > > In short: yes, it's necessary and good to do this. > > -- Justin > ________________________________________ > From: William J. Mills [[email protected]] > Sent: Thursday, March 10, 2011 12:59 PM > To: Richer, Justin P.; Lukas Rosenstock > Cc: Brian Eaton; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > Yeah, but there are serious security problems with credentials in the URL, is > it really worth it in light of those problems? > > ________________________________ > From: "Richer, Justin P." <[email protected]> > To: Lukas Rosenstock <[email protected]>; William J. Mills > <[email protected]> > Cc: Brian Eaton <[email protected]>; OAuth WG <[email protected]> > Sent: Thursday, March 10, 2011 9:49 AM > Subject: RE: [OAUTH-WG] OAuth Bearer Token draft > > Yes, there are many development setups where all you can reasonably access is > the URL to get. It's also much simpler to make use of the well-supported > syntax helpers for query parameters instead of relying on new, custom > formatting for newly-defined headers. The bearer token makes this simple by > just having the value of the token, but other schemes have their own > name/value pair formats and encodings that will inevitably cause hiccups. > > -- Justin > ________________________________________ > From: Lukas Rosenstock > [[email protected]<mailto:[email protected]>] > Sent: Thursday, March 10, 2011 11:49 AM > To: William J. Mills > Cc: Brian Eaton; Richer, Justin P.; OAuth WG > Subject: Re: [OAUTH-WG] OAuth Bearer Token draft > > JSON-P (callback) works with <script> tags where no parameters can be set; > this is used a lot in web applications that want to consume 3rd party APIs > directly on the client side. So, yes, an alternative for the Authorization > header is required - a.f.a.i.k this use case was one of the driving forces > behind WRAP and bearer tokens. > > 2011/3/9 William J. Mills > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > Is there really a need going forward for anything beyond using the > Authorization header? Do we have clients out there that just can't set that > header? Putting bearer tokens in query arguments is a very bad idea for many > reasons, and in form variables has it's own set of badness (although not to > the same level). > > -bill > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
