In the core OAuth spec the scenario is a tightly related token and application
endpoint. It presumes that they will take the appropriate security mechanisms
between them such as signed tokens but doesn't require any particular solution
for how to implement such a mechanism.
When the issue was extended to address discovery based scenarios (a scenario
not currently supported by the core spec) this brought up the problem that a
standard mechanism to provide audience protection is needed. So my article
suggests that when discovery is in scope then we will introduce a standard
mechanism (in my article I suggest a standardized signed token format including
an audience value) to address the issue.
In other words, the current spec leaves the issue unaddressed because it isn't
in scope but when the scope extends to discovery we'll have to provide an
explicit mechanism.
Yaron
From: PRATEEK MISHRA [mailto:[email protected]]
Sent: Friday, September 24, 2010 3:19 PM
To: Yaron Goland
Cc: [email protected]
Subject: Re: [OAUTH-WG] What's the use case for signing OAuth 2.0 requests?
Yaron,
You have referenced the SAML browser SSO protocol (POST profile) in your blog
posting, and correctly observed that the same problem would manifest itself
there as well.
As a counter-measure, the SAML POST profile explicitly requires that the target
(destination) URL or similar identifier be carried as part of the SAML
payload, and, that further the SAML payload is signed. This allows for the
recipient to determine whether it was the intended target and to ignore
payloads directed at other targets.
I dont believe that similar constraints have been placed on the OAuth access
token - it is essentially undefined? - but maybe I missed that in my reading of
the specification draft.
- prateek
My understanding of Eran's article
(http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/)
is that Eran believes that bearer tokens are not good enough as a security
mechanism because they allow for replay attacks in discovery style scenarios.
He then, if I understood the article correctly, argues that the solution to the
replay attack is to sign OAuth 2.0 requests.
In http://www.goland.org/bearer-tokens-discovery-and-oauth-2-0/ I tried to
demonstrate that in fact one can easily prevent replay attacks in discovery
scenarios using OAuth 2.0 and bearer tokens. If the article is correct then it
is not a requirement to introduce message signing into OAuth 2.0 in order to
prevent the attacks that Eran identified.
So this leaves me wondering, what's the critical scenario that can't be met
unless we use sign OAuth 2.0 requests?
Thanks,
Yaron
________________________________
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
