[Openid-specs-ab] Using ID token as JWT assertion grant

John Bradley ve7jtb at ve7jtb.com
Mon Sep 28 17:39:26 UTC 2015


There is a new draft coming soon.

Don’t get to fixated on the terminology of actAs vs On BehalfOf.

If you want a token that only contains claims about the subject then that is the typical onBehalfOf token.
If you want a composite token that contains claims about the subject and the party that you are issuing the token to (likely the client) that would be ActAs.   

They are old terms form WS-Trust that kind of sort of mean that.

So if you wanted to authenticate the client and then issue a token with claims about the user and client, in the case that the party receiving the token wants to differentiate between different kinds of clients, or just needs the info for auditing, then you want a composite token.

In most cases the AS doing the assertion flow may not itself have a client_id for the Client, and only wants to know that the issuer sez the presenter is allowed to access some resource.   That is the single subject use case.

What you want probably needs to be based on the intelligence of the AS doing the assertion flow. 

At some point this will also intersect with the POP work so that the STS can put a proof key in the token for the assertion flow allowing the receiver to determine that the party the token was issued to is the presenter.

So one differentiator in posable trust models is if the client has client ID and credentials for both AS.  
If it has than using a composite token you can get poor mans POP by indicating the client in the composite token and then having the receiver check that the identity of the client in the token is the same as the authenticated client doing the exchange.
The downside of that is that one or both AS have to coordinate client_id mapping making it only something someone really concerned about security would bother with.

Propper POP removes the need for both AS to coordinate the client_id so is more scalable.

John B.
> On Sep 28, 2015, at 1:02 PM, Vladimir Dzhuvinov <vladimir at connect2id.com> wrote:
> 
> Thank you John. I'll take a closer look at
> draft-ietf-oauth-token-exchange to see which exchange type would be the
> correct fit ( act-as vs on-behalf-of).
> 
> Including the OP iss in the ID token audience seems like the best short
> term solution until token exchange becomes final. All clients are
> confidential.
> 
> Vladimir
> 
> On 28.09.2015 18:01, John Bradley wrote:
>> Connect id_tokens are audianced to the client. 
>> 
>> They are not intended to be directly usable in the JWT assertion flow.
>> 
>> In some of the discussions around native apps we talked about creating a flow that allows a client to request a JWT assertion targeted at a different audience.
>> 
>> Google is doing a proprietary extension using structured scope values to get JWT from the token endpoint with a different audience for a related backend (you need to register both client_id in the same project).
>> 
>> The direction at the moment seems to be using token exchange https://tools.ietf.org/html/draft-ietf-oauth-token-exchange to allow clients to securely request tokens that can work in the JWT assertion flow.
>> 
>> In the short term you could issue id_tokens with multiple audiences if you had the administrative rules in place.   
>> You need to consider the posable additional risks of using public clients etc if you start using id_tokens outside of there original use as identity assertions to the client.
>> 
>> John B.
>> 
>>> On Sep 28, 2015, at 10:24 AM, Vladimir Dzhuvinov <vladimir at connect2id.com> wrote:
>>> 
>>> Hi Thomas,
>>> 
>>> On 28.09.2015 15:03, Thomas Broyer wrote:
>>>> On Mon, Sep 28, 2015 at 1:16 PM Vladimir Dzhuvinov <vladimir at connect2id.com>
>>>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Is anyone using ID tokens as a JWT assertion grant to obtain access
>>>>> tokens from an AS?
>>>>> 
>>>> Google is at least using something very similar:
>>>> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
>>>> 
>>> Thanks for the pointer. This is an example of a client-generated JWT grant.
>>> 
>>>>> How do you go about satisfying the requirement that the AS URL (or AS
>>>>> token endpoint URL) must be present in the ID token audience (aud)? (The
>>>>> ID token audience is typically set to the client app).
>>>>> 
>>>> AIUI, the idea is that the JWT is generated *by* the client.
>>>> 
>>> So in that case the ID token should be included as a claim in a JWT
>>> generated by the client? The idea is to enable a client obtain an access
>>> token on behalf of a logged in user by means of implicit consent, but
>>> without having to go through a front-channel OAuth request.
>>> 
>>> Vladimir
>>> 
>>> -- 
>>> Vladimir Dzhuvinov
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> 
> -- 
> Vladimir Dzhuvinov :: vladimir at connect2id.com
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150928/efedf930/attachment.p7s>


More information about the Openid-specs-ab mailing list