Classic IAM was a monolith: one big identity provider that everything authenticated against. That works until the application itself is a swarm of microservices, each needing fine-grained authorization decisions at high speed. A monolithic gatekeeper becomes the bottleneck and the single point of failure.

Cloudentity, Inc.'s US11057393B2, “Microservice architecture for identity and access management” (issued July 6, 2021; CPC H04L 63/105 — security-level access control, and H04L 63/20 — security policy), describes delivering IAM functions as microservices. Read it at US11057393B2.

“Systems and methods for identity and access management are provided in a service mesh that includes a plurality of interconnected microservices. Each microservice is associated with a microgateway sidecar.”— U.S. Patent No. 11,057,393 source

The mechanism turns on one repeated component: the microgateway sidecar. The claims attach a sidecar to each microservice, and that sidecar is the thing that actually enforces access. According to claim 1, the sidecar manages access by “intercepting a request for the associated microservice sent over a communication network from a user device,” where the request carries “data regarding a user context” and an “enriched token.” Instead of a central server adjudicating every call, the decision point is replicated next to every service.

Trust between services is established cryptographically rather than by location. The sidecar enriches a token “based on the user context data associated with profile information of a user,” signs it “using a private key associated with at least one other microservice,” and forwards it; the receiving microservice then “verifies that the token is valid and from the associated microservice based on the signature.” This is the practical content of zero trust for service-to-service traffic: a request is not trusted because it came from inside the network, but because it carries a signed, context-enriched token that the next hop can independently verify.

Above the sidecars sits a policy and risk layer. The claim describes an authorization engine that “accesses a database of security policies for each of the microservices” and “generates a risk profile for the request based on the context data,” then selects from “a plurality of available security workflows” based on that risk. The specification frames the whole thing as a “stateless identity solution built from the ground up on a cloud-native microservices architecture with representation state transfer (RESTful) APIs,” offering “per-transaction authentication, and per-resource authorization.” It even names a “microservice mesh security plane” that co-exists with the data and control planes of a service mesh — a bridge between identity, API management, and the mesh itself.

That is why decomposing IAM matters mechanically: authorization decisions can run close to each service, scale independently, and evolve without redeploying a monolith, because each is its own deployable unit with its own sidecar. The specification calls for behavioral machine learning to deliver “continuous adaptive” authentication across the mesh, and for full lifecycle management spanning users, services, and IoT “things.” The identity layer becomes as distributed and composable as the workloads it guards — which is what makes consistent policy at cloud scale feasible.

The dependent claims show how the risk decision is personalized, not just policy-driven. The user context can include “a user that submitted the request, a device associated with the request, a location associated with the request, and content of the request” (claim 3). Behind that, claim 4 adds “a database of user profiles” where each profile holds “information regarding past requests and corresponding results,” and claim 5 introduces “a behavioral baseline service” that builds “a behavioral baseline model for the user” — which, per claim 6, feeds the authorization engine's risk profile. The result is continuous, adaptive authorization: a request is scored not only against static policy but against whether it looks normal for that user, device, and location. The claims also describe a “proxy plugin that calls the associated microgateway sidecar to validate the intercepted request,” making the sidecar the universal enforcement hook every service plugs into.

The specification is also explicit that this is a deliberate inversion of the old perimeter. It contrasts microservices architectures with “centralized architectures, which are designed as a single, autonomous unit,” and describes a “pluggable microgateway that provides the ease and security that legacy perimeter security like traditional API gateways provided for data centers and monolithic applications” — but “adapted to modern microservices, service mesh deployment models, and capable of custom transformation via configurable plugins.” It frames the system as a “microservice mesh security plane” that co-exists with the data and control planes and serves as “a bridge between identity, API management, and microservice mesh realms,” spanning “full lifecycle management of users/services/things” including IoT. The throughline: the same property that makes microservice applications scalable — many small, independently deployable units — is turned into the security model, with a verifiable signed token as the only currency of trust between them. That is zero trust expressed as architecture rather than as a slogan.

Why this is a business story: this is the architecture thesis behind the wave of API-first, developer-centric identity companies — the ones selling authorization-as-a-service into cloud-native shops. The market reorganized around it: incumbents had to re-platform, and acquirers paid up for teams that had built identity the cloud-native way. The sidecar-and-signed-token pattern this grant describes is, in essence, the productized form of what platform teams otherwise stitch together from a service mesh by hand — which is the value proposition a buyer is paying to skip. Cloudentity itself was later acquired by SecureAuth in 2022, IP and all.

The grounded read: microservice IAM puts a signing, policy-enforcing sidecar next to every service and adjudicates each request by verifying a signed, context-enriched token against a per-service policy and risk engine — making identity as distributed as the apps it guards and removing the monolithic bottleneck. Cloudentity's 2021 grant names that decomposition in detail — the architecture that defined the cloud-native identity market and the deals built on it.