[This article first appeared on The New Stack]

How many times have you or your teams (re)built an authorization system? During the time I was 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. What would a great developer solution look like? We believe authorization for developers should follow five principles:

• Separation of policy and code. Authorization policy 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. Authorization policy should be able to change without a redeploy of the application.
• Secure by default. Policy decisions should default to “no” (a closed system), and should be evaluated in real-time, as opposed to being tied to the lifetime of an authentication token that may have been created hours earlier.
• Service, not 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 for authentication, we need open standards for authorization. A good developer solution should have a multi-vendor 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.

We’re going to expand on each of these principles in its own blog post - sign up to our mailing list to follow the series!

What are your must-have attributes for an authorization service? Leave your comments, or let us know on Medium, LinkedIn, or Twitter.