Arvados

The introspection endpoint is an OAuth 2.0 extension. OAuth 2.0 likes to leave lots of possibilities open. https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method lists 6 different auth methods (plus "none") that the provider might accept at the token introspection endpoint. We might want to choose a subset to support (e.g., whatever would make this work on pingfederate). The provider metadata has a standard place to advertise the introspection endpoint though, so at least we should be able to determine reliably whether introspection is supported.

Access tokens are opaque according to spec, so for example there seems to be nowhere for the provider to advertise which signing algorithms should be accepted. (This is one reason I didn't try to validate tokens independently in #17704.) For serverless validation we'll need to be careful about offering enough flexibility to make it useful, without making it too easy to unwittingly create gaping security holes. Although validating without a callback seems desirable, I'm not especially keen on this feature unless there's a standard for it somewhere. Using the introspection endpoint, and propagating the expiry time it returns, seems like a more standards-compliant way to reduce provider callbacks.

Using "sub" to identify users would certainly be more OIDC-appropriate than using "email". AFAIK the only reason we haven't done this yet is that we have needed to handle a migration between Google and non-Google providers (same email, different sub) but we haven't yet needed to handle the case where the OIDC provider changes users' email addresses underneath us. Unlike the other 2 points, this also affects the normal login process.