[Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect
Michael.Jones at microsoft.com
Fri Nov 11 04:36:43 UTC 2011
Section 4.6.4 of the OAuth Threat Model and Security Considerations<http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01> document contains the following. The highlighting is mine:
4.6.4. Threat: Access token phishing by counterfeit resource server
An attacker may pretend to be a particular resource server and to
accept tokens from a particular authorization server. If the client
sends a valid access tokens to this counterfeit resource server, the
server in turn may use that token to access other services on behalf
of the resource owner.
o Associate the endpoint address of the resource server the client
talked to with the access token (e.g. in an audience field) and
validate association at legitimate resource server. The endpoint
address validation policy may be strict (exact match) or more
relaxed (e.g. same host). This would require to tell the
authorization server the resource server endpoint address in the
I believe we need to follow this recommendation and require an audience in the access token on at least a SHOULD basis, per the decision on the working group call today. If anyone disagrees on security grounds, please say why.
P.S. Requiring encryption to restrict the audience seems like SUBSTANTIAL overkill.
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Thursday, November 10, 2011 6:58 PM
To: Nat Sakimura
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect
With asymmetric keys putting it in the access token works. This is a bit like holder of key confirmation without the TLS.
There are a bunch of security issues with symmetric keys.
The protected resource has to be closely related to the authorization server, as it can masquerade as the
Authorization server or the client with the shared secret.
You may also need to encrypt the token to the protected resource, otherwise it too could leak and you pare back to square one.
On 2011-11-10, at 8:04 PM, Nat Sakimura wrote:
Currently, as it turns out in OpenID Connect, the way to audience restrict
the response of a resource endpoint is to encrypt the response
using the key of the intended client. The server has to keep track of
to whom the access_token was issued, i.e., client audience restriction,
and use the registration information of that client to find out the relevant key.
By doing so, even if the request comes from a rogue party who phished the
legitimate client, the rogue party cannot read the response, so it is secure.
As to the resource endpoint audience restriction is concerned,
it is done implicitly in the sense that as the access_token is opaque,
only the intended endpoint can actually interprete and validate it.
This is how the resource endpoint audience restriction is done
in OAuth 2.0 as I understand.
As it is written right now, how to record both client and resource endpoint
audience restriction is an implementation detail.
I think it should remain implementation detail, but
it is worthwhile to note that somehow the audience restriction MUST be done.
I am ok with RECOMMENDing that these audience to be encoded
in the access_token itself, but would like to let the implementors have
choices on it.
Nat Sakimura (=nat)
Chairman, OpenID Foundation
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab