If a user lacks human traits and doesn’t have much of a personality, there might be a good reason for this. The user might be a machine.

Today, more than 90% of internet traffic is between machines. In reality, machines that consume your B2B SaaS application are also users—just a different kind of user. That’s why every online and SaaS application today must include well-thought-out user management practices and policies specifically designed to handle the different challenges and requirements of machine-to-machine (M2M) interactions.

Based on years of experience helping B2B SaaS companies handle M2M interactions, I’ve put together a quick guide with best practices for efficient, effective, and secure machine-to-machine user management. Let’s dive in.

Know your M2M users and their use cases

Context might be critical in human user management, but it’s even more critical for machines because machine users offer much less information about their status, situation, and intent. Often machine users only access a single service or a small number of services, whereas human users access many more.

Machine-to-machine interactions don’t carry useful clues like browser agent, MAC or NIC address, or geolocation data. They are more likely to be an API call in a commonly used protocol with a bare minimum of identifying characteristics. The context around the service requests that a machine user makes should determine how policies are applied and user management is designed.

For M2M user management, every service must know how it can communicate with other services, and which services it should communicate with. All the services need to know how they communicate with another service and the key services that they must be granted permission to access. This is partly what API gateways and service meshes can deliver, but neither has a user-centric approach (even for M2M users).

Security without multifactor authentication

For human users today, MFA is a critical part of the security validation process. For machine users, MFA is not an option. At the same time, M2M transactions tend to operate in milliseconds, because machines can interact at a much faster speed than humans. This creates a new attack surface area that many cybercriminals are now actively trying to exploit through API attacks. For SecDevOps teams running user management processes against M2M interactions, this means much stricter attention must be paid to other security mechanisms such as IP address limiting, request rate limiting, certificate or key rotation, and, ideally, either human- or machine-generated policies that recognize anomalous usage patterns.

Internal machine users vs. external machine users

Whether a request is from an internal machine or an external user should trigger very different security considerations. If a request is internal, coming from within a Kubernetes cluster from one service to another, then authentication is applied internally and usually with a lighter touch. For example, service meshes are used to set policies on which services any given internal service can connect with. In reality, many organizations are still not authenticating internal machine-to-machine interactions but CISOs and risk management teams are pushing hard to implement baseline authentication everywhere.

To date, many platform operations and SecDevOps teams use naive authentication for internal security—that is, shared secrets. However, naive auth requires a strong process to easily replace secrets that have been violated or somehow exposed. Without this secret swapping process, an organization risks downtime while new secrets are created and shared. At scale, changes to secrets that must be synchronized across pairs or trios of machine users is a lot of work. So even for internal M2M communication, there are technology challenges.

For external M2M communications and machine user management, things get much more complicated. Secret sharing is insufficient security. To demonstrate this, consider the following example. Let’s say we have two services—a user service and an email service. We want to send an email to a user. Not all users are entitled to emails. So to properly manage the user, the application must have awareness of which user is entitled to email and which email should be indicated for messages sent to that user. Secrets quickly break down in this world.

JWTs vs. access tokens vs. client credentials

This use case also highlights why M2M JSON web tokens (JWTs) are preferable to generic M2M communication services. The user management service then must generate a token for a specific user or a specific organization. The token can be revoked or set to require renewals at certain intervals.

A well-designed token lifecycle policy and operational system enables security and user management services to revoke access quickly or rotate keys without operational interruption. Policy is automatically applied via certificate revocation or renewal lists. If renewals are on relatively short timetables, then it’s possible to tune user management to provide near Zero Trust for M2M users. JWTs can carry multiple attributes, so they are particularly useful for encoding context. 

A second way organizations handle external authentication is through the access token—where a user receives a single value string. Here’s how an access token works:

1. The client makes a request to the authorization server sending the client secret, the client ID, and the requested services and scopes.
2. The authorization server validates the request and sends a response with an access token.
3. The client applies the access token to request a secured resource from the relevant service endpoint (API).

An access token is very good for simple transactions but can break down in more complicated scenarios, creating a single point of failure. For example, if for some reason the access token is not validated, there is no easy recourse and no other mechanism to rate trust. Running on a microservice architecture, this implies a more complicated flow that is harder to manage. A machine user would need instant validation going out to a separate validation server and service track. With JWTs, all the service needs to know is whether the user has a valid JWT, which stores all access context. There is no need to run a separate process to validate this.

A third path is client credentials. These are a set of identification information provided by an application, such as a client ID and secret, which are used to authenticate the application and authorize access to a resource server. Client credentials often incorporate JWTs and have the benefit of being more secure because they require two pieces of identification. And while client credentials can be less user-friendly, that is less of an issue when the user is not a human.

However, with client credentials, the system must be designed carefully to enable rapid mitigation of failures and alleviation of bottlenecks. This can be particularly challenging when you are relying on other distributed systems, such as Google or OAuth, or a third-party cloud certificate or token authority. In this scenario, an organization might rely on a JWT that they do not generate or control.

A middle ground between client credentials and access controls might be mutual TLS (mTLS). mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. This layers additional trust validation mechanisms at the handshake point. Some service meshes, reverse proxies, and API gateways apply mTLS by default, but synchronizing mTLS across your entire infrastructure stack requires real system design and careful thought.

Steps toward a strategy

As the number of services and microservices continues to increase, and more applications are architected on top of APIs, developing a strong user management strategy and practice for M2M interactions becomes critical. This means:

• Creating workflow maps of all the elements of your user management stack and all services.
• Identifying services likely to be accessed by machine users and ranking them on criticality, measured in business and security risk.
• Analyzing and deciding which of your M2M user services require which types of authentication.
• Building out an integrated user management stack that delivers on all user management requirements, both human and M2M.

Remember, machines are users, too. You will have to treat them like users to ensure that the services they use are available, fast, scalable, and secure.

Aviad Mizrachi is CTO and co-founder at Frontegg.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.