[Openid-specs-ab] ID Tokens and the client_credentials flow

thomasclinganjones at gmail.com thomasclinganjones at gmail.com
Thu Mar 14 19:26:00 UTC 2019

It sounds like your are saying that the client in the user device has permission to sign with the user’s private key?
That would imply to me that the client was the user?
Not sure how OpenID connect fits into the picture in that case.

If the OP asks the user to sign something for it, then I presume that would be part of the consent process?

It always concerns me from a security perspective when services that are not part of the user are allowed to sign something as the user. That is impersonation, which seems to be absent in the OpenID specs, although I am not fully conversant with all of them. I know that other implementers have added impersonation to otherwise OIDC implementations even tho it seems to be missing from the specs.

thx ..tom

From: George Fletcher via Openid-specs-ab
Sent: Thursday, March 14, 2019 12:08 PM
To: openid-specs-ab at lists.openid.net
Cc: George Fletcher; hga at verizonmedia.com
Subject: [Openid-specs-ab] ID Tokens and the client_credentials flow


We ran into a very interesting use case that OpenID Connect and OAuth2 
don't really address and I'm looking for input on the best mechanism to 

Specifically, we have a way to issue user specific x.509 certificates. 
Given that the certificate references a user, we can use the 
client_credentials flow (with MTLS, private_key_jwt, etc) to obtain an 
access token for the user without involving a browser or UI flows. 
However, there are some contexts where we'd like to get back an id_token 
along with the access_token.

One thought is to use the concept defined by the OpenID Connect spec and 
that is specify a scope of "openid" in the client_credentials flow to 
indicate that an id_token should be returned in addition to the 

Other thoughts for how best to do this in a way that maintains the 
spirit of the specs?

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190314/7ed02ef5/attachment.html>

More information about the Openid-specs-ab mailing list