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

Vladimir Dzhuvinov vladimir at connect2id.com
Mon Sep 28 16:02:48 UTC 2015


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: 3711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150928/96a0b189/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list