Introduction

Whenever an application needs to authenticate a user or needs to obtain information about the user, various tokens are exchanged between the application and the CoreOne Authentication Service. As there are various kinds of tokens, there is usually some sort of confusion. This page tries to help you understand the various type of tokens and their intended use.

JSON Web Token (JWT)

A JSON Web Token is a standardized (RFC 7519) way of storing claims (i.e. your first or last name) in a signed token that contains a header, payload and a signature, encoded as a Base64 string. It is also the most common format to exchange any of the subsequent tokens.

An example of a JWT Token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

Notice the three dots? They divide the token into the three party, header, payload and signature.

Access Token

Access tokens represent the credentials to access a protected resource such as your web application or an API. Any part of your system that needs authorization, can use access tokens issued by an authorization server such as the CoreOne Authentication Service. By passing the access token to the protected resource, the resource can verify the access token by verifying the signature in the JWT token.

This access token does not contain any information about the user except the ID (sub / subject).

Identity Token

Whenever an application requires any information about the user that was authenticated, it should use the OpenID Connect Protocol to get an ID token. This ID token contains the requested information about a user such as the first or last name.

Refresh Token

Both the id token and the access token usually are only valid for a number of seconds as indicated in the exp claim. In order to prolong the access token, there is the concept of a refresh token that can be user to request a new access token without the users interaction. This allows an application to act on behalf of the user even beyond the users interaction. This is done by issuing a refresh token to the application. The application then can exchange that refresh token for a new access token.

Self-Contained vs Reference Token

A self-contained tokens are tokens that contain the claims inside a protected structure such as an JSON Web Token. The recipient of the token has all the information needed inside the token.

On the other hand, a reference token, or sometimes called opaque token, does not contain any information except the reference. This reference, an infeasible-to-guess id, can be used to access the token service in exchange for the required information by using a back-channel communication. Even tough this requires additional calls to the token service, it offers greater security as the token service can immediately revoke tokens as the resource has to go through the resource service each time it needs to validate access.