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.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
