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 enterprise assets.

The traditional approach has been perimeter security and the implementation of protective measures to prevent unauthorized users 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 device 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.

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.

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.