Zero Trust Architecture is a Token-Based Architecture

Zero Trust Architecture Overview

A Zero Trust Architecture (ZTA) is not a single architecture in itself. It is a set of guidelines for the design of systems and operations that intends to tighten the security in order to protect industrial and enterprise assets.

The traditional approach has been perimeter security and the implementation of protective measures to prevent unauthorized users and systems to gain access to the corporate network. It has been mostly about protecting internal resources and networks from external intrusions.

This naturally doesn’t help prevent internal attacks or attacks where an external intruder poses as an internal user. If an intruder can break through the perimeter, it has historically been fairly trivial to move laterally within the network in order to gain further access to corporate resources.

With more resources being moved to the cloud and employees working remote more now than ever the perimeter doesn’t really exist anymore, the traditional models don’t work anymore. This is where a ZTA comes in to play.

Essentially, trust no one (Zero Trust) until they are authenticated and have proven who they are and that they should have access to the requested resource based on a defined access policy. Then apply and enforce access policies that controls what internal users and systems can access.

Where the terms Zero Trust Architecture or Zero Trust Access are typically used to describe the overall broader approach, Zero Trust Network Access (ZTNA) is a term used for products or services that creates the boundary around one or more applications. It's the broker that verifies identity, context, and additional access policies before access to the given resource is granted. It shields the application or service from public view and only allows access to users and devices that have explicitly been granted access.

Zero Trust is a Token-Based Architecture

Authentication is a critical aspect of any successful implementation of a ZTA. It is key in determining if the user is internal or not, what part of the organization does the user belong to, what service is requesting information from another service or even what 3rd party service is requesting access to an internal corporate service.

A token-based architecture is exactly that kind of robust authentication service needed in order to even get started on implementing a ZTA. A token-based approach to authentication can handle all the different types of use cases spanning from users accessing resources to services communicating with other services. It is scalable and highly flexible and is the method to use when it comes to API security and access control of microservices.

Leveraging tokens to authorize access to services is preferred over the use of for example API keys. The main reason being that API keys are static in nature and needs to be configured in the service or proxy in front of the service. If an API key is leaked it needs to be changed/rotated and that could be a cumbersome effort depending on where that give API key is used. A token-based approach is much more dynamic and flexible in nature in the sense that a service or user is taken through a flow to request a token to be used. The protected service validates the token and if it does not contain the correct claims or has expired access will be denied. The calling service or user could then easily request a new token. Tokens could also be leaked just like an API Key but there are built-in mechanisms for revoking a lost token and the architecture is already set up for users or services to request a new token. With this approach, downtime is reduced, and manual labor of revoking API Keys is eliminated.

Tokens

Not all tokens are created equal. There are different types of tokens where the more commonly used ones are opaque tokens and JSON Web Tokens (JTW). Opaque tokens, or by-reference tokens are simply a unique string or identifier. The token by itself doesn't mean anything, it points to a reference of the actual token data that only the issuing identity server knows. Opaque tokens need to be introspected in order to obtain the actual token data.

JWT's on the other hand are tokens that hold the actual data. These types of tokens are excellent to use for transporting attributes. The token itself is signed so they are tamper proof but anyone that has the token can read the information so the use of Personal Identifiable Information (PII) in the token should be avoided.

Tokens should be issued differently depending on what they are to be used for. Claims in tokens are used to validate that the token is used for its intended audience. I.e., if you have a token that is intended to be used for service A you should not be able to use it for service B. This can get complex when a service is communicating with many other services. In these scenarios there are approaches available where a token can be exchanged for another token. Other alternatives are to wrap several tokens inside of another token. That way the main service or API can "pick out" the appropriate token when communicating with other services. Tokens should always be bound to a specific use case, app, or API where they are then used for authorization.

Authentication is key

With authenticating every access request to a resource, internal or external, the authentication component becomes key in the ZTA. There needs to be lots of flexibility in the type of authentication performed to handle both users and services. All resources are also not equal so there will be scenarios where some type of step-up authentication is needed for more critical resources where Multi-Factor Authentication (MFA) is probably preferred. Users will move around from service-to-service and accessing different resources and with that Single Sign On (SSO) will play an important role.

With passwords being one of the weakest forms of authentication the approach of passwordless authentication has been gaining momentum for a while. There are many forms of passwordless authentication and new approaches available in the market on a regular basis. The more common approaches are a One Time Password (OTP) code sent via email or SMS. These are easy to implement and somewhat user friendly but are also not phishing resistant, i.e., an attacker can inject themselves in the flow and intercept the OTP code. A better option is leveraging a phishing resistant passwordless approach such as WebAuthn with a hardware token like YubiKey.

In the process of authentication there will also be the level of confidence in the authentication to consider. This is where additional inputs such as time of day, geo location, risk score, etc. would come in to play to augment the authentication method itself in order to calculate what the confidence of the given authentication is. If the score indicates an unacceptable level of risk, maybe there needs to be alerting/reporting and additional factors invoked in order to raise the confidence level of the user’s identity.

Conclusion

With authentication happening with every request for access to a resource, authentication becomes critical in implementing a ZTA. A token-based architecture maps extremely well to handle this for both users and services. The broker responsible for verifying the identity in ZTNA will essentially verify an access token whether access is requested by a user, device, or another service.

Organizations should move towards gradually implementing a ZTA in order to protect their resources. Start with critical resources and determine the requirements for strong authentication including MFA and SSO approaches to strengthen the security but also to make the transition smooth for end users. See the Implementing Zero Trust APIs article for further details on integrating zero trust into your applications.