2

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://datatracker.ietf.org/doc/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?

Community
  • 1
  • 1
sunsin1985
  • 2,437
  • 5
  • 22
  • 27

2 Answers2

3

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.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • Thanks! In my scenario, there is actually no difference between the resource owner (user) and the client. Hence, as per my understanding, if the resource owner/client is requesting an access token from the authorization server using the 'JWT-BEARER' grant then there is no need to obtain any 'id_token' with the same information. If the access token is passed to another party afterwards, then the only way for that party to obtain the user information would be to invoke the /userinfo endpoint as described in the Open ID Connect spec. Is my understanding correct? – sunsin1985 Aug 04 '15 at 22:36
  • That would be mixing up OAuth 2.0 and OpenID Connect: an access token may be used to obtain user info but that does not necessarily mean that the user is present (anymore) and it does expose information about the authentication event itself (e.g. timestamp, method) and other metadata (e.g. audience). See also http://oauth.net/articles/authentication/ – Hans Z. Aug 05 '15 at 06:05
0

There is nothing in the spec says that an oidc scope can't be supported. So it can be inferred either way. I am going with the assumption that if an authentication was performed to get the initial JWT then it will fine to return an id_token. I am however continuing to research on this. Until then taking the approach of also sending an id_token if the client is sending an oidc scope in the token call.

skavi
  • 1
  • 1