A Bearer token is an opaque string, it has no intrinsic meaning and the contents cannot be read to decode any infomration.

Where as Jwt tokens are

• Signed
• Self contained
• Resource server can verify the access token and read the content without having to go back to the auth server

Bearer/opaque token postives and negatives in OAuth context

Opaque tokens are not self contained ie the content cannot be read to decode information. When resource server receives an opaque token , it must check with auth server for token info/validity etc.

These cetralized checks of opaque access tokens

• Increases the load on auth server
  • if the auth server is single point of failure then this is all the more dangerous.
• Increases latency for client as well .
• Token revocation how ever is easy as every hit from client to resource server is leading to a hit to auth server.

JWT tokens positives and negatives in OAuth context

Signed self contained access tokens which the resource server can read/decode (after signature validation) and decide if the user is authorized or not.

• No checks against auth server are needed.
• Reduces load on authserver
• Reduces latency for client
• But the problem in this approach is that signed jwt access tokens cannot be black listed by auth server as the resource server does not even contact the auth server.

Note that refresh tokens can be used to revoke access (although it will not be immediate)