Hacker News new | past | comments | ask | show | jobs | submit login

My apologies, it's been a while and I was forgetting about the authorization-code exchange step. So yes, for the most part "client"s can treat the bearer token as opaque. But "resource server"s absolutely cannot.

> If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS endpoint.

If it's a JWT, which it doesn't have to be. OIDC allows the token to either be an RFC 6750 opaque token, or an RFC 7523 JWT, and overwhelmingly implementations use a "bearer" (6750) token. But, most of the time it's a JWT, so as I said, closing your eyes and pretending it's a 7523 token works, and so then you can just pull the keys from the JWKS endpoint.

> Introspection is standardized and an RFC.

In my experience, it is exceedingly rare for an IDP to implement RFC 7662 token introspection

> All these URLs are defined and provided via the .well-known/openid-configuration endpoint.

Yeah, OIDC-discovery is pretty sweet. And if the IDP implements OIDC-discovery, then it probably implements OIDC-core, or at least enough of it that you can use the user-info endpoint, like I mentioned. But I've seen IDPs that don't.

Have you ever used OAuth2 outside of OIDC?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: