Should API consumer send id_token or access_token for openIDConnect security scheme

With the addition of the openIdConnect security scheme object type in v3, I find the spec ambiguous on whether the API consumer should be sending an id_token or an access token to the API.

From my understanding, this may not have been an issue in v2 since there was only oauth2 instead of oauth2 and openIdConnect. Since OpenIDConnect flows can provide both id tokens and access tokens, which token type should be sent to the API? Does specifying an auth type of openIdConnect imply that an id_token should be used, while oauth2 implies that an access_token should be used? If so, I think this information should be explicit in the spec instead of implied. If not, could you comment on whether or not consumers should always be sending an access_token for both oauth2 and openIdConnect security scheme types?

[lkgarrison]

Thanks for the detailed reply Phil. It would be great to see this guidance appear within the spec itself to help eliminate confusion for API consumers.

[pleothaud]

Hi there,

The problem is complex (is the OpenID Connect Provider also an OAuth Authorization Server for the API? Are the access token opaque tokens or JWTs? etc), but in short id_tokens are JWTs intended for Client Applications use, not for Resource Server (API) use.

id_tokens are there so that the Client Application can authenticate the end-user, they contain potentially sensitive information about the end-user that you as the Client Application developer/owner might not be allowed to transmit to the Resource Server (the API).

So don’t send id_tokens but access_tokens to the API. The API can then invoke the token introspection endpoint to get information about the end-user and the scopes the client application requested.

Hope it helps,

Phil