How many times have you or your teams (re)built an authorization system?

Throughout my career I've seen companies do this more than once or twice. During my time as the CPO at Puppet, we built (or rebuilt) authorization systems at least three times across our product portfolio. We did it not because it was a unique source of differentiation, but because our customers needed to integrate our products with the identity and access systems and processes they already had.

It’s the “cost of doing business” for having an enterprise-grade SaaS product. And as much as we would have liked to avoid reinventing this wheel, there wasn’t a developer API for authorization that we could utilize, in the same way, that we used Auth0 for authentication or Stripe for payments.

Indeed, Authorization is broken. This is why Broken Access Controls is the #1 threat on the OWASP top 10 list of application threats.

Authorization service for developers

What would a great developer solution look like? At Aserto, we believe authorization for developers should follow five principles:

• Separation of policy and code. Authorization logic should be lifted out of the application and expressed in its own textual representation that is independent of the application’s language and framework. This “policy as code” should be stored and versioned in its own git repository, which is controlled by the application administrator. This enables separation of concerns and the independent evolution of the authorization policy, which once decoupled can change without a redeploy of the application.
• Secure by default. Access decisions should default to “no” (a closed system), and should be evaluated in real-time. This is in contrast to the all to common use of baking permissions into authentication access tokens. In these cases, access is tied to the lifetime of the authentication token that is not only hard to invalidate, but might have been created hours or days earlier.
• Authorization service, not a library. Delivering a developer solution as a library instead of a service is like delivering server software instead of SaaS — which is to say, quickly becoming extinct. A developer service provides a central point of control and takes care of the operational burdens of running at scale — both critical reasons why developers trust services like Stripe for payments or Auth0 for authentication.
• Open, standards-based. Much like we have JWT, OAuth2, and OpenID Connect for authentication, we need open standards for authorization. A good developer solution should have a multivendor open-source underpinning, and be part of a broad ecosystem.
• Easy to integrate. A great authorization service helps you fall into the “pit of success” with sensible conventions that are prioritized over complex configuration. It integrates with your existing identity and directory providers and offers a variety of hosting models. It has bindings and samples for every language and framework, so you get it integrated in five minutes, or your next one’s free.

These are the five principles that authorization systems for developers must follow. In the past few year a handful of vendors have built services that adhere to most if not all of these principles. Examples include Aserto, Open Policy Agent, OpenFGA, and Topaz open-source authorizer

Conclusion

Broken access controls is the #1 threat on the OWASP top 10 for good reason. Authorization is broken. In this post, we shared five principles that any authorization service built for developers should follow. An authorization service for developers must be easy to integrate and have an open foundation. It should also decouple policy from code and implement deny by default.

We built Aserto based on these principles. Sign up for free today to try it for yourself. We'd love to hear what you think- drop us a line, or join our community Slack.