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

John Bradley ve7jtb at ve7jtb.com
Fri Nov 11 02:58:28 UTC 2011


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/20111110/6089e265/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/20111110/6089e265/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list