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

Nat Sakimura sakimura at gmail.com
Fri Nov 11 01:04:05 UTC 2011


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

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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111111/6e126ce7/attachment.html>

More information about the Openid-specs-ab mailing list