Francisco,
>> 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. > But why would a legitimate authorization server redirect the > client to an attacker's server? It can happen the other way around. The 1st service acts maliciously, forwarding a token that was actually obtained from the 2nd service. The client then uses that token to make requests to the 2nd service - because it thinks it is part of the 1st service. The core issue is that a client gets a opaque token from one service and will use it to access other resources. The token is opaque to the client: 1. The client cannot check that the token was originally issued by this service (as opposed to this service forwarding a token from elsewhere); 2. The client cannot check that the token was meant for itself (as opposed to being forwarded from another client); 3. The client isn't told by the token issuer where it should & shouldn't be used (ie the boundary of the services); 4. The client isn't told by a resource server which sources of tokens are legitimate. One way to avoid some of these issues is to hardwire clients to a specific service - which is very limiting. Another way is to have a standard token format - which is limiting, and a big burden on clients. A better way is to accept points 1 & 2; address 3 by listing resource sites in token responses; and address 4 obliquely by listing the authorization server in the "Origin" HTTP request header. Then it doesn't matter if a client unwittingly connects with an attacker's service (just as it shouldn't matter to a legitimate web site if their web browser clients unwittingly visit malicious or compromised web sites). -- James Manger
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
