Integrations – elaborating a selected topic for project managers: token characteristics and their use

This blog presents an integration topic from a project manager’s viewpoint: tokens.  Are you managing integration projects? Were you ever mixed up in technical jargon that only a few specialists understand, while the time to solve a key issue was running out? Did you file tickets at various suppliers, which in the end bounced back to you? Then this blog may help you.

This blog covers token characteristics and their use. A better understanding enhances overview, helpful to drive a complex issue to a solution. Notions may be simplified here, so exceptions are possible. Practical challenges are given. This blog builds on a previous blog on basic token concepts, recommended to read first. As a followup, this blog dives in more detail.

Token characteristics and their use

Various tokens exist, such as JSON Web token (JWT), bearer vs. non-bearer token, opaque vs. self-contained token, id_token and (OAUTH) access token. Such characteristics are certainly not mutually exclusive. For example, a bearer token is often self-contained, but not necessarily. The characteristics and their use will be outlined below.

JWT
The use of a JSON Web Token (JWT) is common: easy to implement, ensuring authenticity, excluding signature tampering, and able to carry data such as authorization claims, validity period and more. JWT fits efficient processing, allowing local validation, based on secret keys. Security deserves careful attention, to avoid token data ending up in the wrong place.  JWT’s work especially well in distributed systems and in a microservice architecture, designed for independent processing.

Bearer vs. non-bearer token
For a cinema ticket, anyone who presents the ticket will be granted access. In token jargon, the equivalent is a bearer token. Only its validity is checked, not (necessarily) the identity.

The most prominent example of a bearer token is the JWT, typically used in stateless interactions. It simplifies the alignment between client and server, without the need to maintain state. This is especially helpful for larger transaction volumes.  

When access is not to be granted to anyone presenting the token, then the caller’s ID (user or application) must be authenticated. Token inspection serves that purpose (see previous blog).

Opaque vs. self-contained token
The token provides data, by retrieval from the token itself, and/or through external lookup.

An opaque token consists usually of a meaningless character string. It only makes sense after an external lookup (i.e. server side validation, called introspection), normally with the token issuer – e.g. the OAUTH authorization server.

A self-contained token, on the other hand, allows to retrieve data from the token itself, without external lookup (only client side validation, called inspection), applying signature verification, decoding it and verifying the integrity of the token. Locally stored keys are sufficient to enable this, but the keys have to be managed securely.

While the loss of an opaque token is less risky, it consumes more resources, due to the external lookup that is needed, affecting performance.  A bearer token such as JWT is typically self-contained. OAUTH access tokens on the other hand, are commonly (but not necessarily) opaque.

OAUTH access token
The OAUTH protocol can be implemented in many ways. After obtaining an id_token as a first step (not part of OAUTH, please refer to the section on OIDC below), that token is submitted in the second step (using the OAUTH protocol). Thereupon, the OAUTH authorization server (compare with the ticket booth of the cinema) provides a (short-lived) OAUTH access token, which is submitted when calling the API at the resource server (comparable to the cinema itself). The OAUTH access token deals with authorization (permissions). The resource server verifies the validity of the OAUTH access token with the issuing authorization server.

The characteristics of an OAUTH access token are typically opaque and non-bearer.

OIDC and OAUTH
OAUTH focuses on authorization, and does not provide a standard way for authentication. Authentication in conjunction with OAUTH is possible, but then you have to build your own authentication process, which can be avoided by implementing OpenID Connect (OIDC). OIDC  extends OAUTH with an identity layer for authentication purposes, by delivering an id_token and an OAUTH access token. Authentication through OIDC is standardized, applying standardized endpoints, user data and  supporting single sign on (SSO) across multiple applications. On the other hand, OIDC adds complexity and may be considered as overkill for simple use cases.

Practical cases

What situations might occur in practice?

1. Organizational.  Ensure that the right skills are involved, especially in extended integration chains. The details between the parties must be aligned.

• Design.  Determine what token characteristics work best, depending on security requirements and (potential) performance challenges:
• Bearer (e.g. JWT) or non-bearer (e.g. OIDC/OAUTH)
• Local inspection (of a self-contained token) or by external lookups (opaque token)
• What is the source of the ID (passed on in a token, or by lookup)
• How authorizations fit in (permissions, OAUTH authorization flows)
• Fit in an integration chain, between several parties

• Realization. Implement logging/monitoring/alerts in such a way that token issues can be pinpointed effectively.

• Operations. Implementation of OIDC/OAUTH depends on several endpoints (Identity Provider, Authorization server, Resource server, …). Frequent technical availability checks avoid unnoticed downtime that block the integration chain.

• Challenges. Token design must be carefully balanced with high transaction volumes – the latter favors local inspection if feasible. Integration chains with public access may require additional security, also affecting token design.

Summary

Tokens provide an essential tool to successful integrations. The technology is well known, but you may encounter challenges. This blog presents token characteristics and their use, to assist you in overcoming such challenges when they occur. More topics will be covered in subsequent blogs.