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

John Bradley ve7jtb at ve7jtb.com
Mon Nov 14 12:37:07 UTC 2011


I agree that where the access token is a JWT it must contain an audience restriction.

I would go further to say describing how to use JWT as access tokens is provably a valid topic for an extension spec.

What confused me is that you started off looking for a countermeasure to:
4.6.4.  Threat: Access token phishing by counterfeit resource server

This is important but not a effective countermeasure to this attack.

John
On 2011-11-14, at 9:15 AM, Mike Jones wrote:

> No, I’m not proposing that the client understand anything about the audience in the access token.  I’m proposing that the issuer of the access token include an audience restriction within the token stating that it is intended for consumption by the UserInfo endpoint for the OpenID Provider.
>  
> This is standard audience semantics in which the intended recipient of a token is recorded in the audience claim of the token.  Nothing complicated or special is intended.
>  
> Yes, let’s talk about it during today’s call.
>  
>                                                             -- Mike
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net]On Behalf Of John Bradley
> Sent: Monday, November 14, 2011 3:20 AM
> To: Anthony Nadalin
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect
>  
> From what I understand of Mike's proposal.
>  
> He is proposing that the client also use information in the access token to determine what resources it can send the token to.
>  
> This is a separate issue from the protected resource determining if it is the intended audience of the token.
>  
> Perhaps we can discuss it on today's call.
>  
> John
> }On 2011-11-14, at 4:06 AM, Anthony Nadalin wrote:
> 
> 
> > 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
>  
> Not sure what you mean by encoded in the access_token, I assume you mean that there is a aud_restriction claim in the token, not that the token is encoded somehow that the receiving parties can decode?
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net]On Behalf Of Nat Sakimura
> Sent: Thursday, November 10, 2011 5:04 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect
>  
> 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/20111114/e40d7f55/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/20111114/e40d7f55/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list