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

John Bradley ve7jtb at ve7jtb.com
Mon Sep 28 15:01:19 UTC 2015

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

-------------- 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/73b77d35/attachment.p7s>

More information about the Openid-specs-ab mailing list