maxkabakov - Fotolia
Use tokens for microservices authentication and authorization
Independent and interoperable microservices require a permissions rethink, or you'll drive users crazy. Examine how tokens come into play for authentication and authorization.
When assembled correctly, a microservice architecture gives applications interoperation between various services, possibly hosted across different platforms. For microservices, security must be top of mind, since there's no way to contain users as in a monolithic application.
Instead of simply allowing upfront access to a microservices-based application, development teams need to also secure and manage access for each user-facing service. However, users do not want to be challenged every time they move from one service to another. New security approaches maximize protection in a distributed architecture without inhibiting user experience.
In this tip, we review the basics of how to manage access in a distributed architecture and examine the role that token-based security plays in microservices authentication and authorization.
Authentication and authorization in microservices
The first key to unlock microservices security is authentication and authorization:
- Authentication determines who you are by validating that a particular entity is actually what it claims to be.
- Authorization regulates what you are allowed to do through assigned roles and classes that define the various permissions a user has.
With the right tools in place, an application can perform authentication once per session, while still allowing authorization to occur multiple times as a call moves from one microservice to another.
For microservices authentication, go beyond the basic challenge-and-response system, based on usernames and passwords alone. Instead, the user-facing microservice should perform multi-factor authentication (MFA), relying on a separate authentication app on a user's device or perhaps a physical token like an RSA SecurID tag. This microservice authentication approach will also require a security token service (STS).
The history of microservices token authentication
The concept of the STS stems from service-oriented architecture, when WS-Trust became a standardized security protocol for token management. WS-Trust was originally modeled around SOAP and used languages like SAML to distribute tokens in the form of XML documents, also known as SAML Assertions.
The movement toward distributed web-app development caused software teams to look for security tokens that worked with RESTful and JSON formats. Some of the token technology that arose from this need include JSON web token and OAuth 2.0.
Security token service
STS enables clients to obtain the credentials they need to access multiple services that live across distributed environments. It issues digital security tokens that stay with users from the beginning of their session and continuously validate their permission for each service they call. An STS can also reissue, exchange and cancel security tokens as needed.
The STS must connect with an enterprise user directory that contains all the details about user roles and responsibilities. This directory, and any connection made to it, should be properly secured as well, otherwise users could elevate their permissions just by editing policies on their own. Consider segmenting user access policies based on roles and activities. For instance, identify the individuals who have administrative capabilities. Or, you might limit a developer's access permissions to only include the services they are supposed to work on.
A basic outline of how such a system works is shown in Figure 2.
First, a user logs into an application and provides authentication details through a challenge-and-response system that is supported by MFA. Then, the STS uses information derived from the MFA to determine which token to provide the user at the start of the session. This token remains with the user throughout the session, still managed by the STS, and each service the user tries to access checks the token to allow or deny access.
Securing automated access
Not all microservices permission and security checks are based around a human user. Automated components also generate microservices access requests. Consider the rise of the internet of things, which has led to a massive growth in the use of automated devices. These devices transmit their own data across networks and access any number of services, either for data analysis or to trigger certain functions. Since many of these activities are event-driven, they have almost zero dependency on human intervention.
The above microservices authentication and authorization approaches are still valid in these scenarios, except that MFA doesn't work for non-human components that can't interact with end-user devices or physical tokens. In these cases, it's best to embed any automated component that accesses your services with a unique identifier, such as an embedded serial number, that the STS can use to verify what tokens it should issue. Technologies like OAuth and OpenToken provide ways to embed these devices with unique identifiers.
