The Five Principles of Authorization

Image credit: Takahiro Sakamoto on Unsplash

[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:

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 LinkedIn or Twitter.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store