[OAUTH-WG] OAuth Tokens and URI's

[Jim Manico]

Torsten,

The
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1
guide you are working on is a special kind of magic. Thank you for
taking the time to write this very important document.

When it comes to 2.2.1, I see your great suggestion to prevent referrer
leakage. These defenses are very important, and I appreciate how clearly
you laid these out.

But I think they skip the really core problem that web security
solutions must embrace - which I believe to be, /do not put sensitive
data in URL/GET parameters/. This goes all the way back to RFC 2616
#9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of
taking an action other than retrieval" which I feel implies "should not
do anything dangerous" including transport sensitive data.

OAuth 2 goes pretty wild - all the way - with putting very sensitive
tokens in URIs/URLs and I have seen some solutions that break the
"standard" and POST/PUT/PATCH when they can, keeping tokens out of POST
actions, URL's and similar. Is this worth discussing?

Thank you again for this very important and well written document.

Aloha from Hawaii,

[Jim Manico]

... One more note. You mentioned in this section...

o Use form post mode instead of redirect for authorization response

.. This might be worth expanding on./Use form post and keep data OUT OF
THE ACTION/ (which is essentially the same as a GET). Safe transport of
tokens includes well configured HTTPS, POST and other verbs, and data
being the body of the request, not in the action of a form. Fair?

(And sorry, I missed this one the first time around)

Aloha, Jim

Post by Jim Manico
Torsten,
The
https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security-topics/?include_text=1
guide you are working on is a special kind of magic. Thank you for
taking the time to write this very important document.
When it comes to 2.2.1, I see your great suggestion to prevent
referrer leakage. These defenses are very important, and I appreciate
how clearly you laid these out.
But I think they skip the really core problem that web security
solutions must embrace - which I believe to be, /do not put sensitive
data in URL/GET parameters/. This goes all the way back to RFC 2616
#9.1.1: "the GET and HEAD methods SHOULD NOT have the significance of
taking an action other than retrieval" which I feel implies "should
not do anything dangerous" including transport sensitive data.
OAuth 2 goes pretty wild - all the way - with putting very sensitive
tokens in URIs/URLs and I have seen some solutions that break the
"standard" and POST/PUT/PATCH when they can, keeping tokens out of
POST actions, URL's and similar. Is this worth discussing?
Thank you again for this very important and well written document.
Aloha from Hawaii,
--
Jim Manico
Manicode Security
https://www.manicode.com