IAM is composed of two distinct concepts: Identity—often referred to as authentication—and Access Managment—often referred to as authorization. Because both of these concepts share the same nickname, “auth”, it’s easy to conflate the two. Because the market for Identity vendors has been well established for many years, platform teams have typically onboarded their organizations onto a solution for authentication. However, most platform teams have yet to realize that they can also consolidate authorization.

Implementing authorization per-application is full of landmines

When the platform team has offered no solution, the status quo for development teams is to implement their own ad-hoc authorization logic in their applications. This is the path of least friction for an application developer getting started, but this solution ages like milk. Application developers don’t have the time to spend researching and designing a flexible authorization framework that will keep them confident in its security as the product expands its capabilities and makes foundational changes to its design. If an organization has or is adopting a microservices architecture, the pain is only further exacerbated because application developers are only responsible for their services and aren’t focused on designing anything that works across teams. These are difficult constraints for any aspect of development, but it’s even scarier for authorization because it’s security critical: one mistake and it’s game over.

JWTs aren’t a solution

This is a good point in time to reflect on a particular ubiquitous technology: JSON Web Tokens. While tokens are an effective solution for stateless authentication, they do not fix many of the aforementioned pitfalls of per-application authorization. Beyond the obvious observation that JWTs have size limitations, they also have consistency limitations. JWTs are notorious for having no means for revocation; this means that if a user’s permissions are altered, previously issued tokens remain valid, potentially granting access to resources that should now be restricted.

Taking inspiration from the pioneers at Google

When Google was faced with the challenge of building an authorization system that would work across their entire portfolio of services (e.g. Calendar, Drive, GMail, YouTube), they built an internal system from scratch that could be operated by a single team. Google named this system Zanzibar and documented it in an academic paper in 2009. The novelty behind this system was that it approached authorization by building a service dedicated to owning not only the logic, but also the data used to make decisions. By centralizing as much as possible, they could design a more resilient system that could be better reasoned about in terms of performance, but also correctness.

Why centralize?

By following Google’s lead and centralizing authorization across applications, there are many benefits to reap. The most obvious benefit is deduplication of any authorization logic that was otherwise built into each application. Deduplication pays dividends when changes are necessary and you find the change only has to occur in one place rather than changing bespoke code in various applications. Once there’s only a single place for authorization, it also becomes significantly easier to reason about correctness of the overall system; it’s even possible to use tools and model checking to prove this correctness before rolling out a change to production. It might seem counterintuitive, but by centralizing authorization, the authorization system becomes less of a single-point-of-failure. This is because the centralized system has a focus on being critical and can be designed from the ground up to be more scalable and fault tolerant than your typical cloud application.

Conclusion

It’s time for platform teams to take ownership of the full “auth” stack and provide a robust, centralized solution for both authentication and authorization. Until this best practice has become ubiquitous we will continue to be beholden to privilege escalations exploited against authorization systems yet to be wrangled. Don’t wait until your security lapse makes the headlines—take action now.