In the (back)end, JWT is all that matters

What standards are relevant to securing access to REST APIs? OAuth 2.0 springs to mind, perhaps OpenID Connect (OIDC), as well as JSON Web Tokens (JWT). But, actually, looking at the problem in a narrow sense, only the latter matters: a REST provider does not care how consumers obtain their security tokens. And that, after all, is what OAuth 2.0 is, a standardised protocol for a client to obtain an access token. OAuth does not standardise the token's format. This is in contrast to OIDC, which not only specifies the protocol, but also the ID token format. Maybe that is a bit of an overstatement. It would be more accurate to say that OIDC limits the degrees of freedom of an ID token: it should be a JWT and it should contain a handful of mandatory claims. Alongside, it can contain a whole host of other claims as well.

In an OpenID Connect dance, an API consumer forwards the access token to the API provider

But the client is not meant to forward the ID token to the REST service, only the access token. In spite of the lack of standardisation, the industry seems to have been inspired by the OIDC ID token and consensus seems to be emerging that an access token should also be a JWT, possibly including ID token mandatory claims. Other claims remain to be negotiated between token issuer and REST provider. Usually the former can be configured to include attributes such as roles or group membership.

So, the bottom line is that REST API providers should be agnostic of how an access token is obtained. Perhaps one day, there will be better alternatives to OAuth 2.0 and OpenID Connect and as long as the authentication and authorisation dance results in a JWT token, the REST server will not know or care. Is JWT here to stay? Perhaps, perhaps not in its current form. But that is a topic for another post.