Re: [OAUTH-WG] Indicating sites where a token is valid

[Torsten Lodderstedt <[e-mail]>]

Am 07.05.2010 08:14, schrieb Manger, James H:
>
> > what about an additional realm response value?
>
> My original 
> suggestion(http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html) 
> had a “realm” in addition to “sites”. I still think that should be 
> present (though more to match the HTTP auth model (RFC2617) than an 
> expectation that it will be used by most services).
>
> > If there is a binding between realm and token, the client can decide 
> based on the realm attribute discovered using a WWW-Authenticate 
> response which token to use.
>
> “realm” is not sufficient, however. A “realm” doesn’t stop you sending 
> a token to a bad site. Even if an app makes and unauthenticated call 
> first, there is nothing to stop the bad site responding with a 
> WWW-Auth header with the right “realm” value so the client app will 
> reveal the token.
>
> -- 
>
> James Manger
>

I didn't have that threat on my radar screen so far, thank you for your 
advice.

Let me describe what I understood so far from this thread and your 
previous posting. I see two different scenarios:

1) Resource server controls token sites (context of the realm attribute)

The realm returned in a WWW-Authenticate header is by default valid 
within the resource servers site (scheme + host-Part of the URL?) only. 
This way, a bad site cannot automatically get access to tokens intended 
for other sites just by spoofing  the realm attribute. Using an 
additional "sites"-attribute in the WWW-Authenticate-Header, the 
resource server could indicate on which sites the given realm is 
considered equivalent. This broadens the context a realm is valid in. It 
is the resource server which authorizes the usage of tokens on other 
sites by the client. If the clients encounters the same realm on a site 
listed in "sites", it is authorized to automatically use the token there.

2) Authorization server controls token sites (context of token)

If I interpret your current proposal correctly, you suggest the 
authorization server may determine on which sites a particular token can 
be used. That way, the authorization server explicitly authorizes usage 
of tokens based on the trusted relationship between resource server and 
authorization server. This is an interesting proposal since it could be 
used to prevent any bad site from token abuse and unauthorized access to 
private user data. The later is especially relevant if unencrypted, 
self-contained bearer tokens are used.

Attack scenario:
Assumption: User X has an account with site "https://www.example.com" 
where he stores his private data
1) The users intends to configure its mobile OAuth client for access to 
"https://www.example.com", but unfortunately uses the wrong URL 
"https://www.bad_example.com" obtained from an attackers e-Mail
2) "http://www.bad_example.com" respondes with the authorization URL of 
the OAuth server of "https://www.example.com"
3) The user authorizes access for "https://www.example.com" (or at least 
believes to do so)
4) The client acquires an access token from the authorization server
5) The mobile client access "https://www.bad_example.com" using that 
access token
6) "https://www.bad_example.com" proxies the request to 
"https://www.example.com", so neither the user nor the service realize 
the problem

I see the following ways how "https://www.bad_example.com" could abuse 
the token:
a) It can access the users private data on "https://www.example.com" or 
deposite illegal files (file sharing).
b) It can read the private user data contained in the token

If we follow your proposal, the authorization server would respond with 
a response value of "sites": ["https://www.example.com"] in step (4). 
The client would detect the attack attempt and refuse to send any 
request with the token to "https://www.bad_example.com".

In my opinion, (1) improves security and eases the practicability of 
OAuth2 in scenarios with multiple sites and (2) is a significant 
security improvement. I think, both scenarios should be addressed by the WG.

Any thoughts?

regards,
Torsten.