[Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect

John Bradley ve7jtb at ve7jtb.com
Sat Nov 12 14:21:34 UTC 2011


Nat's email was about audience restricting the response from the user-info endpoint, not the request.

So different issues.

The issue below is how to stop the client from sending the bearer token to a counterfeit resource server.
Access token Phishing.

I thing the explanation below is a bit rubbish.

This is not a typical use of audience.  Normally only the end recipient of a token validates that it is the intended recipient.

I think Mike is suggesting that an intermediary looks inside the token to determine who the valid recipients are before it sends it.

This would be a useful feature (A bit WS-Security), but would only be useful where the access tokens are JWT, WS-Security or SAML.

I expect that some basic processing rules about who you send access tokens to would be a more general solution.

The gets the resource server endpoint during discovery and associated that with the access token in some sort of table. 

Where there are additional scopes and endpoints bound to the token that gets more complicated.   
A good argument for getting the aditional tokens via the distributed claims mechanism.

John
On 2011-11-10, at 11:36 PM, Mike Jones wrote:

> Section 4.6.4 of the OAuth Threat Model and Security Considerations 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.
>  
>    Countermeasures:
>  
>    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
>       authorization process.
>  
> 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.
>  
>                                                             -- Mike
>  
> 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.
>  
> John B.
>  
> On 2011-11-10, at 8:04 PM, Nat Sakimura wrote:
> 
> 
> Hi. 
>  
> 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
> http://nat.sakimura.org/
> @_nat_en
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111112/cffcfbdb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111112/cffcfbdb/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list