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 basic token concepts. 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. If you care, a lot more detail is available on the Internet. A subsequent blog covers token characteristics.
Tokens
Tokens are used mainly for two purposes.
- A web application, accessible from a browser, for a human user to interact
- An API, for applications/mobile apps/services to interact with another.
Within that context, an external application grants access by both:
- authentication – verifying a user’s identity, requiring user login/password or passwordless policy
- authorization, to control access permissions to selected resources
Traditionally, authentication by user login and password was sufficient. Today, a more robust authentication method is available, applying shorter validity and increased security. Tokens were designed to fill the gap. While the concept is simple, there is a whole world behind it. This blog explores the basic concepts.
Metaphore
A token compares to a cinema visit: buy a ticket at the ticket booth, while the actual entrance is separate. Like a movie ticket, the token is “short-lived”, to reduce risk. Once the token expires, it can no longer be used. Validation of a token requires a chain of trust, like for TLS certificates.
If there are multiple movies on show in the cinema, then your ticket mentions the right movie (authorization). In the same way, a resource server may have several resources ‘on show’, calling for proper authorization.
Authentication
One major token purpose is to authenticate the user or client application. To access a web application, usually a login and password suffices, with additional multi-factor authentication (MFA). However, in order to grant a client application the access to an API, more sophisticated authentication is needed. The ID may be accommodated in various ways, including:
- A JSON Web Token (JWT). After the user logs in, the responding server issues a JWT containing the authenticated ID. Subsequently, the caller presents that token to an API, and the responding server validates the token.
- an ID token: the user logs in through a third party application (e.g. Google or Facebook), resulting in an ID token. The caller uses that ID token to obtain an OAUTH access token from the authorization server, with short validity, to access the resource server.
- a session token (containing stateful information), usually stored as a cookie at the client. This is normally used by a browser to access an external application.
More details on token characteristics will be given in a subsequent blog.
Inspection & validation
A token contains or represents ID data, but potentially also other data, e.g. authorization claims. Data can only be extracted by inspecting the token, on server and/or client-side. The main purpose of token inspection is to validate the token, on various levels, depending on the use case:
– format check, to verify correct use
– signature check, to verify integrity & authenticity
– expiration check, to verify if the token is valid
– identity information (claims about user)
– claim extraction (e.g. intended audience claim, authorization claims)
– token type check (access or a refresh token)
In some cases, the design allows for client-side validation (only), when the token contains all necessary data, in order to avoid external lookups that may affect performance. In case of external lookups, to retrieve e.g. granted permissions, the design must cater for server-side validation.
Authorization
Historically, authorization was retrieved from (associated with) the identified user account. Meanwhile, it has been recognized that authorization details in a token bring several benefits, such as:
- Additional security, e.g. recognizing limitations before access is granted
- Dynamic permissions, enforced by the token
- Instant determination of permissions, without database lookup and without the need to maintain state
Refresh token
Tokens are short-lived. In order to avoid login repetitions, a long-lived refresh token comes together with the short-lived access token. After expiry of the access token, the refresh token can be used (if still valid) to request a new access token. Consider it as a ‘subscription’ token.
Practical cases
What situations might occur in practice?
- Organizational. Involve the right skills, addressing business requirements, design, technical expertise. Oversights will cause delay.
- Design. Let the architect(s) select the best token solution, addressing security and performance. If ID tokens originate elsewhere (e.g. Google or Facebook), for reuse in an integration chain, then ensure architectural alignment.
- Realization. Details are important, such as token claims, OAUTH authorization flows, alignment with application roles.
- Operations. Pay attention to key management, for encoding/decoding and token validation, with secure storage. Adequate expiry times are strongly recommended. The whole purpose of token use is obliterated, if a long-lived expiry time has been defined – when done ‘for simplicity’s sake’.
Challenges. Several token mechanisms are at disposal. Be careful however, integrations affect two or more parties. Check the compatibility of the applications involved. If not, fewer options remain.
Summary
Tokens provide an essential tool to successful integrations. The technology is well known, but you may encounter challenges. This blog presents basic token concepts, to assist you in overcoming challenges when they occur. A subsequent blog provides more detail on token characteristics.
