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

Mike Jones Michael.Jones at microsoft.com
Mon Nov 14 12:15:53 UTC 2011


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> [mailto:openid-specs-ab-bounces at lists.openid.net]<mailto:[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<mailto: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<mailto: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/35455c27/attachment.html>


More information about the Openid-specs-ab mailing list