Suppose I have a web application that uses OpenID Connect to enable users to log in with one of several 3rd party identity providers (e.g., "log in with Google", "log in with Facebook"). I do not associate the 3rd party identities with a local identity (there is no way to bind a Google account and a Facebook account like you can with StackExchange).

Now suppose I want to add an API protected by Bearer authentication (RFC6750). This uses OAuth 2.0 access tokens. My questions:

  • Can these tokens be issued by the 3rd party identity providers? Or do I have to run my own OAuth server and somehow bind the access tokens to the 3rd party identities (example)?
  • If the tokens are issued by the 3rd party identity providers, and those tokens are opaque strings (not RFC9068 JWTs), how would my server know which identity provider's introspection endpoint to query when validating the token? I could query all identity providers in parallel and see which one succeeds (if any), but that would expose the sensitive bearer token to many 3rd parties, right?
  • What makes you think a 3rd party ID provider issues tokens as "opaque strings" and not JWTs?
    – Beltway
    Jan 12, 2022 at 9:14
  • @Beltway I'm referring to the Bearer (access) tokens, not ID tokens. ID tokens must be JWTs, but the access tokens are opaque to the client. RFC6749 section 1.4 says, "The string is usually opaque to the client." RFC9068 section 1 says, "The original OAuth 2.0 Authorization Framework specification does not mandate any specific format for access tokens." Jan 12, 2022 at 22:24
  • Access tokens don't need to be opaque to the RP, but in practice there's a mix of implementation-specific strings and JWTs. IIUC, there was no de jure standard access token format that RPs could depend on until RFC9068. Jan 12, 2022 at 22:24
  • The tokens' opacity towards the client is required in the sense that it should not be concerned about its contents as mentioned in the RFC. However, you referred to OpenID specifically, and from my state of knowledge (couldn't find it in the specs after a quick search) OpenID relies on JWT exclusively (and the most common ID providers I have worked with do). If in any case this should not apply, your server would still have to extract the well-known endpoint out of whatever token type provided.
    – Beltway
    Jan 13, 2022 at 8:03
  • @Beltway node-oidc-provider intentionally issues opaque access tokens by default. (I'm using that package for testing purposes.) How to determine the userinfo/introspection endpoint from the token is precisely my question. Maybe that's not possible if all of the tokens I get are opaque strings (to the resource server). Jan 14, 2022 at 0:21


You must log in to answer this question.

Browse other questions tagged .