Accueil > OpenID Connect OAuth Server dedicated > Develop > OpenID Connect > Issuing Access Token as JWT

Issuing Access Token as JWT

The Brent Shaffer’s oauth2-server-php Library allows issuing Access Token as JWT.
With this feature, OAuth 2.0 and OpenID Connect authorization code flows look very similar, however ...

See :

Configuring the Authorization Server for JWT Access Token

Inside the librarie, this is done by setting configuration parameter "use_jwt_access_tokens" to ’true’ :

  1. $config = array(
  2.     ...
  3.     'use_jwt_access_tokens' => true,
  4.     ...
  5. );


For the configuration of OAuthSD, the file /commons/configure_oauth.php and configure_oidc.php both define the USE_JWT_ACCESS_TOKENS constant, set to ’false’ by default.

With OpenID Connect flows, when configured to ’true’, the Token Controller issues both Access Token and ID Token as JWT.

  1.   access_token: string = "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZCI6ImYzNDExNjM3Mjc2ZjJjMzUxZjczYz
  2. ...
  3. VFx1Rk972S4ON1Dn6FwadTDS2U_A"
  4.   expires_in: long = 3600
  5.   token_type: string = "bearer"
  6.   scope: string = "openid profile"
  7.   id_token: string = "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJvMnNwLmRuYy5nbG9iYWwiLCJzdW...
  8. m6TFdfGhgjPyIA0w"


Use Case

Listen to Brent Shaffer [1] :

"you can use JWT Access Tokens if you have distributed systems, and need to validate a token’s authenticity by more than one party without having to make a network call.

For instance, a token is granted by the Authorization Server. That token is a JSON Web Token signed by the Authorization Server’s private key. The Resource Servers (where API calls are made) are spread out all over the world, running multiple applications. As long as the Resource Servers have the Authorization Server’s public key, which does not need to be secured, they can validate the tokens quickly without any network calls. The tokens don’t even need to be persisted.

It’s an enterprisey use case, but is very useful for distributed systems."


This feature has been defined in 2014, at a time the OpenID Connect was under construction. It probably aimed giving OAuth2 users the capacity to validate access tokens in resource servers.

We must also consider the problem posed by OAuth : it is not an authentication system (but authorization) because the access token is opaque and does not give information on the end user. By incorporating the user ID into the JWT token, OAuth is made an authentication system that passes user information to protected resources. That’s what Facebook does with what they call the "signed request".

With this feature, OAuth 2.0 and OpenID Connect authorization code flows look very similar.
However, we must note the difference between access token and identity token : they are not related in time. The notion of "OIDC" session is based on the validity of the identity token, that expires, while the access token expires independently, can be refreshed, or may not expire. This use of the access token as JWT can not replace the OpenID Connect identity token.

JWTs can be used as OAuth 2.0 Bearer Tokens to encode all relevant parts of an access token into the access token itself instead of having to store them in a database. This could be very valuable with session-less applications (like single page application), with a reduced latency of token validation.