Search code examples
oauth-2.0jwtaccess-token

Confusion with OIDC and access token scopes

I am implementing API accessible only for users with specific scope, classic scenario. However I quite don't understand some things about access tokens.

Access token is JWT

I think this is straightforward, I just receive JWT, verify it, read scopes.

But since access token format isn't normalized, that JWT could contain anything. Should I just assume that scopes are there every time? Does every IdP put them in it?

Access token is opaque (or JWT doesn't have scopes?)

I need to call introspect endpoint and retrieve data from it.

But RFC7662 section 2.2 says that literally only required data in the response is bool active, the rest is optional.

What exactly does "optional" mean here?

  • the field is optional and won't be present if it's empty, otherwise it always be

or

  • it might be missing even though the token has associated scopes
Access token is opaque and there is no introspect endpoint?

I found this post on Auth0 forum explaining their opaque and JWT tokens.

Opaque Access Tokens issued by Auth0 can be used with the /userinfo endpoint to return a user’s profile.

and

In order to receive a JWT you must include an audience parameter with your token request.

In this case I don't see any way to get scopes since they don't support token introspection. What am I missing here?

So in case of my implementation to be conformant for every OIDC IdP:

  • If it's JWT, check scopes in it
  • If it's not JWT, introspect it and check scopes in the response
  • If it's not JWT and there is no introspection endpoint, ???

Anything else I should need to know / worry about?

Solution

  • I don't think you should aim to support every possible IdP, as many libraries expects and assumes the token is using the JWT format and won't work if your IdP uses reference tokens instead of JWT.

    For example, for ASP.NET Core, the default JWT Library for authentication does only support JWT tokens.

    Typically, your API, that you build, will only authenticate and trust tokens from one provider, typically, the one that you control and own (Either inhouse or as a service).

    If you want to support social login, where users can for example login using Google and FaceBook, then that is arranged through your own IdP and your IDP will never deal directly with tokens from those providers.

    A typical setup will look like this

    enter image description here