Support for ID tokens in introspection endpoint

[Mitar]

Introspection endpoint is defined in the OAuth 2.0 spec, but not really covered in the OpenID Connect spec. Some time ago check ID endpoint was dropped. Currently strict reading of the OAuth 2.0 spec would be that introspection endpoint can be used only for access tokens by a protected resource and not also for ID tokens. But multiple implementations in fact support passing ID tokens to the introspection endpoint:

• Okta accepts ID token on introspection endpoint: https://developer.okta.com/docs/reference/api/oidc/#introspect
• Ping Identity accepts ID token on introspection endpoint: https://www.pingidentity.com/en/company/blog/posts/2020/token-introspection-pingone-for-customers.html
• Google has tokeninfo endpoint which to me looks like introspection endpoint and it accepts ID token

I wonder, is there already somewhere specified/documented/hinted that ID tokens can be passed to the introspection endpoint and how to do so in a safe manner?

I think it would be useful for this to be allowed, but I think to be done safely (for token substitution attack not to happen), caller should pass an expected audience parameter to it and introspection endpoint should return active response only if the parameter matches any of the aud claims in the token itself.

Anyway, what are thoughts here. Should this already be supported by implementations? Or is this something which is not a good idea to do?

[Brian Campbell]

The implementations suggest some latent demand for some kind of ID token introspection but I think it’s largely misplaced and shouldn’t be standardized or encouraged.

[Vladimir Dzhuvinov]

Why do you want to have ID tokens introspected in this way?

The OAuth 2.0 token introspection endpoint is intended primarily for tokens that aren’t self contained (e.g. JWT) and the consumer has no other way to verify them but to call the authZ server.

That some products have ID token introspection is not an argument to retrofit this to the OIDC spec.

[Michael Jones]

As discussed during 1-Nov-21 working group call, this proposes new OAuth 2.0 functionality - not OpenID Connect functionality. This could be proposed to the OAuth working group, but it's out of scope here. Note also that OpenID Connect does not use introspection.

[Mitar]

‌

The OAuth 2.0 token introspection endpoint is intended primarily for tokens that aren’t self contained (e.g. JWT) and the consumer has no other way to verify them but to call the authZ server.

‌

It is simply simpler to call the server sometimes to validate the token than to fetch the key and run the validation yourself. You can also get it nicely pared without having to pull in a JWT library.