Should API consumer send id_token or access_token for openIDConnect security scheme

[lkgarrison]

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?

[MikeRalphson]

Ping @isamauny - do we need more clarity in the spec here? My understanding was that the openIdConnectUrl (such as https://meechum.netflix.com/.well-known/openid-configuration) was used in place of the type: oauth fields to obtain the necessary oAuth2 configuration (flows, scopes etc) to connect with the described API. Though I'm not sure on the specific question of access_token vs id_token posed above.

[lkgarrison]

Whether the consumer should be sending an access_token vs an id_token seems like an important part of the spec - can anyone comment on whether OASv3 can/does tell the consumer which token type should be sent to the API?

[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

[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.

[kishoreaetna]

Yes, it would be helpful to include this guidance specs. This is an important aspect that is often not understood.

[LasneF]

OIDC and OAuth 2 follow the same convention: to make a call to an endpoint (i.e., to access an API), you need to provide the access token.

The ID token is for identity, not for access. It essentially represents who you are, whereas the access token is the actual key to open the door.

The identity provider will provide you with both the ID token and the access token (and sometimes a refresh token). In most cases, if you request only the ID token, you cannot use it to access the API