Open ID Connect with JWT Bearer Token Grant Type

Question

I am working on a use case where I am trying to achieve the following:

1. Use the OpenID Connect protocol. Spec is here: (http://openid.net/specs/openid-connect-core-1_0.html)

2. Issue a call to the /oauth2/access_token endpoint with:

   a. For resource authentication: Use grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer This is as per the spec (https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12)

   b. For client authentication: Use client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer This is again as per the same spec as listed in the point #a above.

My question is:

I know the Open ID Connect spec only talks about the "Authorization Code" and the "Implicit" grant scenarios. However, I am planning to use the Open ID spec in combination with the JWT Bearer spec. In other words, send the authentication and authorization information in a single call to the OAuth2.0 token api (/access_token) via the JWT Bearer Grant Type and receive an access token and id_token in return. Is this possible or would I be going against the Open ID Connect spec?

Answer 1

This is not defined in in the spec because it would be a circular reference: OpenID Connect's primary function is to authenticate users to a client through an id_token that is delivered to the client. The id_token is a JWT that describes user and authentication properties. A client receives a so-called grant from the user to obtain the id_token with that user's information.

If the grant is a JWT already that is (necessarily) tied to the user and the authentication event there's no need to get another one that basically describes the same (essentially that's what the Implicit grant achieves). If the grant is not tied to the user authentication, it cannot be used to obtain an id_token since that would violate the semantics of OpenID Connect.

Therefore the JWT Bearer grant type makes sense in OAuth 2.0 (delegated authorization) scenario's but not in OpenID Connect (user authentication) scenario's.

Of course it still possible to use a JWT (that is unrelated to the user and/or user authentication) for client authentication purposes but then it is not used as a grant but as an alternative for a client secret in an Authorization Code grant.