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

Anthony Nadalin tonynad at microsoft.com
Mon Nov 14 07:06:04 UTC 2011


> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111114/2b4a9e46/attachment-0001.html>


More information about the Openid-specs-ab mailing list