[Openid-specs-ab] [openid/connect] Messages - Add 'prn' claim to id_token to support JWT Assertion (issue #687)

Torsten Lodderstedt torsten at lodderstedt.net
Thu Dec 27 19:28:43 UTC 2012


So the id token is essentially also becoming an access token? 

How is it different from the access token the client also obtains from the OP? Especially, if the additional audiences shall be requested using scope values. 

Let's assume the following: "openid myserver1 myserver2"

Would the OP add myserver1 and myserver2 to both tokens?

regards,
Torsten.

Am 27.12.2012 um 18:49 schrieb John Bradley <ve7jtb at ve7jtb.com>:

> The audiences would be determined by the Authorization server policy and perhaps indicated by the client via scopes.
> 
> So one thing would be to have the audience of the AS to use the ID token in the assertion flow now that we are changing user_id to match JWT.
> 
> The other is some set of related clients.
> 
> A client with a related server might register itself as having two client ID.  
> 
> When the native app portion requests a login it gets back a id token that contains bot itself and the related server as the audiences.
> The client could then use the assertion flow to exchange the id_token for a access token at the related service. 
> 
> This is a sort of federated login for apps.  People do this a bunch of insecure ways now.
> 
> However if I have an app that hat relies on Google or some other OIDC provider for authentication, I need some safe way of passing that authentication to my AS.
> (Some clients will just pass the id_token directly as a access token though I don't think that is an especially good idea.)
> 
> So yes I can see an AS as an additional audience, it however may be one associated with the client and not the OIDC provider.
> 
> John B.
> 
> On 2012-12-27, at 2:12 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
>> I agree with you for the general JWT case, esp. for multi-audience access tokens.  
>> 
>> What are examples of multiple audiences in id tokens? Given the original posting, I assume this might be the client_id and additionally the authorization server itself. This would allow the client to use this token in the assertion flow. How is the client supposed to control the audiences to be included? Or is this determined by the authorization server's policy?
>> 
>> regards,
>> Torsten.
>> 
>> Am 27.12.2012 15:18, schrieb John Bradley:
>>> I don't think that having multiple audiences for JWT is a bad thing as long as the recipients know what is going on.
>>> 
>>> If we put it in the spec then people with closely related RS or multi part clients can use it safely.   
>>> We can also include advice that if you get a multi audience bearer token it could be coming from any party listed in the audience as well as the AS.
>>> 
>>> I am more comfortable discussing the issues and saying when a multi-audiance token may not be appropriate, vs people going around the spec not understanding the issues.
>>> 
>>> John B.
>>> On 2012-12-27, at 4:52 AM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
>>> 
>>>> Isn't the obvious alternative to have different tokens with each having a single audience value? It would at least prevent token abuse by resource servers (w/o proof of posession).
>>>> 
>>>> Regards,
>>>> Torsten.
>>>> 
>>>> Am 20.12.2012 um 15:29 schrieb John Bradley <ve7jtb at ve7jtb.com>:
>>>> 
>>>>> Yes if we have multiple audiences then who the token is issued to is probably only useful if there is some sort of proof of possession to go along with that.
>>>>> 
>>>>> Google's use-case for cid could probably be solved with multiple audiences, rather than cid as they are not doing any proof of possession.
>>>>> 
>>>>> The thing is that is you receive a token with multiple audiences then you need to assume that any of the parties listed as a audience might have sent it to you.
>>>>> 
>>>>> I think that is a easier security concept for most people to get there heads around than thinking cid is special somehow without proof of possession.
>>>>> 
>>>>> So I suspect in the end we need multiple audiences and a way of doing proof of possession. They are interrelated but not the same.
>>>>> 
>>>>> John
>>>>> On 2012-12-20, at 10:50 AM, Brian Campbell <bcampbell at pingidentity.com> wrote:
>>>>> 
>>>>>> Without some additional authentication or proof, I don't see what "cid" really provides?  
>>>>>> 
>>>>>> My intent only went as far as getting support for multiple audiences into the base JWT spec so there's some flexibility for other types of token exchange use case. I get that it might have implications in Connect but I don't know if they need to be codified yet.
>>>>>> 
>>>>>> And, at the risk of picking another fight with the gentlemen from Google, I'm not yet convinced that what they've done with "cid" as some kind of intermediate audience claim is something that should be standardized. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, Dec 18, 2012 at 6:17 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>>>>> If we were to allow multiple audiences in a OIDC id_token it raises the question of how a client requests additional audiences and what it means to a client that receives a id token from that contains multiple audiences.
>>>>>>> There are also UI issues to consider around what consent the user is asked for.
>>>>>>> 
>>>>>>> This overlaps with the google use  case where the requester is identified in a separate claim.
>>>>>>> 
>>>>>>> It may be a useful thing to indicate the actual requester of the JWT when there are multiple audiences.
>>>>>>> 
>>>>>>> Allowing for a client to get a token that can be presented as part of an implicit flow to a third party with them as the audience opens up a security hole.
>>>>>>> 
>>>>>>> I would be OK if we allow multiple audiences in the ID_token where the client ID of the requester is identified, as long as we do not allow tokens with multiple audiences in the implicit flow.
>>>>>>> 
>>>>>>> So the normal case would be aud as a literal and the 'cid' is implicitly the same as 'aud'.
>>>>>>> 
>>>>>>> If 'aud' and 'cid' differ then the 'aud' is an array of one or more values, and cid is the identifier of the token requestor.
>>>>>>> 
>>>>>>> Then the id_token could be used in an assertion flow though I would prefer that cid have some linking to the client making the assertion flow request.  perhaps there is a way to do that using a proof of possession key.
>>>>>>> 
>>>>>>> Without proof of possession it is not really any worse than a single AS with multiple RS                             via scopes.  The UI at the authorization server is the hardest part.
>>>>>>> 
>>>>>>> You are being asked to grant client X a assertion granting it permission to access service y on host foo.
>>>>>>> 
>>>>>>> The id_token probably needs to contain some sort of scope info for the target AS to make a decision on.
>>>>>>> 
>>>>>>> From a engineering perspective I like it.  From an explaining it perspective it complicates things.
>>>>>>> 
>>>>>>> John B.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 2012-12-18, at 9:01 PM, Brian Campbell <bcampbell at pingidentity.com> wrote:
>>>>>>> 
>>>>>>> > BTW Justin, I got focused on other aspect of all this and forgot that
>>>>>>> > I wanted to ask you what (assuming aud and prn/sub/who/etc work out)
>>>>>>> > this exchange actually looked like? The JWT Assertion is designed for
>>>>>>> > the case of trading a JWT for an access token but it sounds like you
>>>>>>> > are using it to get an id token? Is that in place of the access token
>>>>>>> > or does it supplement it?  Do you send an openid scope in the request?
>>>>>>> > Just curious really...
>>>>>>> >
>>>>>>> > On Fri, Dec 14, 2012 at 3:40 PM, Justin Richer <jricher at mitre.org> wrote:
>>>>>>> >> You are correct. I hadn't caught that, but it does state in JWT Assertions:
>>>>>>> >>
>>>>>>> >> The JWT MUST contain an aud (audience) claim containing a URI reference that
>>>>>>> >> identifies the authorization server, or the service provider principal
>>>>>>> >> entity of its controlling domain, as an intended audience. The token
>>>>>>> >> endpoint URL of the authorization server MAY be used as an acceptable value
>>>>>>> >> for an aud element. The authorization server MUST verify that it is an
>>>>>>> >> intended audience for the JWT.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Which doesn't leave much wiggle room for the OIDC interpretation. Between
>>>>>>> >> this an 'prn', maybe this is a different kind of assertion claim, then? An
>>>>>>> >> id-token assertion grant type?
>>>>>>> >>
>>>>>>> >> -- Justin
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On 12/14/2012 04:51 PM, Brian Campbell wrote:
>>>>>>> >>
>>>>>>> >> I believe the current wording of the specs would prohibit that.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Fri, Dec 14, 2012 at 2:10 PM, Justin Richer <jricher at mitre.org> wrote:
>>>>>>> >>>
>>>>>>> >>> My original idea is for the Client to use the JWT Assertion flow with a
>>>>>>> >>> current id_token to refresh it and get a new id_token. This goes back to the
>>>>>>> >>> session management proposal linked to within the issue. In this case, the
>>>>>>> >>> audience for the token really *is* the client, and an AS will need to look
>>>>>>> >>> for that.
>>>>>>> >>>
>>>>>>> >>> -- Justin
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On 12/14/2012 04:04 PM, Brian Campbell wrote:
>>>>>>> >>>
>>>>>>> >>> I had a comment/question related to the below comment on issue 687 but not
>>>>>>> >>> really related to the issue itself. So figured the list would be the best
>>>>>>> >>> forum.
>>>>>>> >>>
>>>>>>> >>> Regarding the potential use of an ID Token as an assertion in the OAuth
>>>>>>> >>> JWT Assertion Profile - aren't the requirements around the "aud" claim also
>>>>>>> >>> potentially a problem?
>>>>>>> >>>
>>>>>>> >>> Connect says the aud of an ID Token "MUST be the OAuth 2.0 client_id of
>>>>>>> >>> the Client." While the OAuth JWT Assertion Profile is a little more flexible
>>>>>>> >>> but basically says the aud must identify the AS or its controlling entity.
>>>>>>> >>> Doesn't this imply that an ID Token could only really be used to get an
>>>>>>> >>> access token within the scope of the client to whom it was sent in the first
>>>>>>> >>> place? Which doesn't seem very useful. Or is it?
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On Thu, Dec 13, 2012 at 5:23 PM, Michael Jones
>>>>>>> >>> <issues-reply at bitbucket.org> wrote:
>>>>>>> >>>>
>>>>>>> >>>> --- you can reply above this line ---
>>>>>>> >>>>
>>>>>>> >>>> Issue 687: Messages - Add 'prn' claim to id_token to support JWT
>>>>>>> >>>> Assertion
>>>>>>> >>>>
>>>>>>> >>>> https://bitbucket.org/openid/connect/issue/687/messages-add-prn-claim-to-id_token-to
>>>>>>> >>>>
>>>>>>> >>>> Michael Jones:
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> I agree that it would be a shame, architecturally, if we can't use an ID
>>>>>>> >>>> Token as a assertion in a way that complies with the OAuth JWT Assertion
>>>>>>> >>>> Profile.  I believe we need to address this.
>>>>>>> >>>>
>>>>>>> >>>> There are few ways to do this, as I see it:
>>>>>>> >>>>
>>>>>>> >>>> 1.  Add "prn" to the ID Token.  Upside:  Simple.  Downsides:  Wastes
>>>>>>> >>>> space through duplication of data; potential interop problem where not
>>>>>>> >>>> everyone duplicates or uses the information in the same way.
>>>>>>> >>>>
>>>>>>> >>>> 2.  Replace "user_id" with "prn" in the ID Token.  Downside:  Less
>>>>>>> >>>> mnemonic than user_id.  Upside:  simple.
>>>>>>> >>>>
>>>>>>> >>>> 3.  Modify the OAuth JWT Assertion Profile to allow the subject to be
>>>>>>> >>>> identified by a claim other than "prn" - possibly explicitly calling out
>>>>>>> >>>> "user_id".  Upside:  would work.  Downside:  Codifies inconsistency.
>>>>>>> >>>>
>>>>>>> >>>> 4.  Replace both "user_id" and "prn" with a different claim in both
>>>>>>> >>>> specs.  Candidates include "id" and "sub".
>>>>>>> >>>>
>>>>>>> >>>> Let's make this a topic for Monday's call.
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> --
>>>>>>> >>>>
>>>>>>> >>>> This is an issue notification from bitbucket.org. You are receiving
>>>>>>> >>>> this either because you are the owner of the issue, or you are
>>>>>>> >>>> following the issue.
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> _______________________________________________
>>>>>>> >>> Openid-specs-ab mailing list
>>>>>>> >>> Openid-specs-ab at lists.openid.net
>>>>>>> >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >>
>>>>>>> > _______________________________________________
>>>>>>> > Openid-specs-ab mailing list
>>>>>>> > Openid-specs-ab at lists.openid.net
>>>>>>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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/20121227/6efeed9f/attachment-0001.html>


More information about the Openid-specs-ab mailing list