Access Tokens

The Access Token is conceptually the same as an entrance ticket, with information about a user or application packaged as a JWT token or just a random string. It is used by a resource server (API) to allow the call or not and it should not be used by the client at all. A client should not pass the ID Token to the resource server.

The access tokens created by Authway is passed as Bearer tokens to the resource server. Authway supports two different types of access tokens that are configured per client:

  • JWT tokens
  • Reference tokens, which is just a random string. This random string is exchanged for token claims when the resource server uses the introspection endpoint. The resource server must identify itself when calling the introspection endpoint.
  {
   "iss": "https://instance.irmciam.se",
   "nbf": 1311277370,
   "iat": 1311280970,
   "exp": 1311281970,
   "client_id": "client",
   "jti": "44CE5DT8B9F8E7F2DCB231ED6C546BE8",
   "scope": "api1",
   "token_type": "access_token",
   "active": true
  }

An Access Token has these features:

  • Specifies the issuing authority, represented with a iss claim.
  • Is generated for a specific application, called client in OIDC and represented with a client_id claim.
  • Has an issue (iat claim) and expiration time (exp claim) as well as a not before time (nbf claim).
  • A unique identifier of the token, represented with the jticlaim.
  • The scope that the access token is inteended for. The resource server should validate the scope to be sure that the access token is inteended to be used for this resource (or not).
  • May contain other claims about the user and/or client, like name and email, depending on what claims are configured to be part of the scope.

In the case of introspection the returned claims will also have these features:

  • A value indicating if the token is still valid, represented with the active claim.
  • The type of token.