On Tue, Apr 6, 2010 at 11:15 AM, David Recordon <record...@gmail.com> wrote: > There is potential for leakage if the client then redirects the user to > another SSL URL. This doesn't feel like a common pattern and the client > would generally be redirecting to a page which they control after receiving > the access token. > From 15.1.3 of RFC 2616: > Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP > request if the referring page was transferred with a secure protocol.
There are several ways tokens passed on URLs tend to leak. I think I listed them all in the security considerations. [1] If the callback URL points to a page that links to third-party content, the third-party content will get a copy of the URL, including the access token, via the referer header. Search for 'referer' in the browsersec wiki [2] for the gory details. If the callback URL is an open redirector, it might be tricked into sending the access token to an untrusted third-party. If the web server logs requests, the access token will end up in the web server logs. Passing the token on the fragment mitigates all of those risks. Callback URL whitelisting is also important. Time-limited access tokens are a final layer of defense. There are some intrinsic risks here - I'd like to make sure that we treat lightweight javascript clients (no secrets, transient data access, authenticated only by callback URL) different than full-fledged web servers (can keep secrets, permanent data access.) Note that it's pretty easy for a web server to pass an access token down into a javascript widget. So I think there's a clear upgrade path from the one mode to the other. Cheers, Brian [1] http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations [2] http://code.google.com/p/browsersec/wiki/Part1#Hypertext_Transfer_Protocol _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
