On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > Q. Should an OAuth client app list the authorization server in the Origin > header of requests to resource servers?
They are allowed to, but are not required to, by the Origin header specification. Whether they should or not is a question for the OAuth working group to decide. Adam > In OAuth (delegation) flows a server dynamically issues credentials (such as > a bearer token) to a client app to use in subsequent HTTP requests to other > servers. To combat login cross-site request forgery (CSRF) attacks [1] > (where an attacker’s server issues the attacker’s credentials to a client > app to use on behalf of a victim at a legitimate server) the client app > needs to indicate where the credentials came from. The Origin header [2] > looks like the right place to indicate this. > > > > [For the OAuth list: The Origin HTTP request header “indicates the origin(s) > that caused the user agent to issue the request” > [http://tools.ietf.org/html/draft-ietf-websec-origin-00#section-6.2].] > > > > [For the WebSec list: An OAuth credential from an authorization server is a > bit like a cookie, but not restricted to the same origin.] > > > > > > Example: > > > > Client to (malicious) authorization server: -> > > POST /token HTTP/1.1 > > Host: login.example.com > > … > > <- > > HTTP/1.1 200 OK > > … > > { "access_token": "SlAV32hkKG", …} > > > > Client to resource server: -> > > POST /uploadData HTTP/1.1 > > Host: api.exampledata.com > > Authorization: BEARER SlAV32hkKG > > Origin: https://login.example.com > > … > > > > > > There can be other servers that contribute to a client app making a request. > For instance, one server can redirect to another. A Origin request header > can list multiple origins. The server will not be able to distinguish which > origin issued OAuth credentials from which issued a redirect etc. That might > not matter if a server has to trust all the values listed in the Origin > header. > > Q. Is it the group’s expectation that servers checking the Origin header > will require all the listed origins to be trusted? > > > > [1] Robust Defenses for Cross Site Request Forgery, > http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf > > [2] The Web Origin Concept, > http://tools.ietf.org/html/draft-ietf-websec-origin > > [3] Principles of the Same Origin Policy, > http://tools.ietf.org/html/draft-abarth-principles-of-origin > > > > -- > > James Manger > > > > _______________________________________________ > websec mailing list > web...@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
