Hi Francisco,
>> Q. Should an OAuth client app list the authorization server >> in the Origin header of requests to resource servers? >> >> 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 ... > But how will the client app get the "credentials" (bearer token) > from the wrong authorization server? A client app hardwired to use a specific single service cannot get a token from the wrong server. If the client app additionally never follows redirects or any other instructions from the server will not send the token to another service. Such an app is safe from login CSRF attacks, but hardly needs a interoperable web spec. A client app that goes to whichever service a user points it at could get a token from any authorization server. For instance, a photo framing app that asks for the URL of your online photo store. A client that follows HTTP redirects (or Link: header or any other variety of hypertext) might get directed to an 2nd service while still using the token from the 1st service. I don’t see any way for a client to know the boundaries of an OAuth2 service – other than preconfigured service-specific knowledge. OAuth2 draft 10 said clients “MUST NOT make authenticated requests with an access token to unfamiliar resource servers”. Clients were assumed to be “familiar” with every server they contacted – the antithesis of web architecture. Later drafts don’t even have that language (it probably got lost in the doc split). I have previously argued for a ‘sites’ field in a token response to indicate where the token can be used. A client would still need to use the “Origin” header as protection against a malicious ‘sites’ value. [ http://www.ietf.org/mail-archive/web/oauth/current/msg02587.html Spec text for “sites” field] -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
