Ever wondered how fine-grained authorization intersects with APIs and gateways? It’s a topic that Omri Gazitt, Co-founder and CEO at Aserto and Co-chair of the OpenID AuthZEN Working Group, took the time to explain at the recent Tyk LEAP 2.0 API governance conference. Inspired by Omri’s session, we’ve rounded up the key points below, including these top takeaways:
- The pain points of authorization
- What we can clean from tech giants’ authorization patterns
- How AuthZEN combines the best of the ABAC and ReBAC cloud native authorization ecosystems
Any dive into authorization starts with a quick word on the difference between authentication and authorization. Authentication is about proving that you are who you say you are. Authorization comes once you’re logged in, determining what can you do in the context of the application.
For authentication, we have mature standards (OpenID Connect, OAuth 2.0, SAML) and a set of mature developer services: Auth0, Azure Active Directory, Incognito and so on.
Comparatively, authorization is still the Wild West. There are no standards that have reached the same level of maturity (although AuthZEN aims to be the OpenID Connect of the authorization world). There also aren’t any developer services that are mature at scale, although Aserto and various other companies are trying to do that. This means developers have to roll their own – and there’s a lot of pain associated with that.
Authorization pain points
Chief among the authorization pain points is security – hence OWASP putting broken access control as number one on its top ten list of security vulnerabilities. OWASP states that a staggering 94% of applications it tests exhibit some form of broken access control.
Inconsistency across microservices in terms of how authorization is implemented is another problem, making it very difficult to figure out who has permissions to what.
Then there’s opportunity cost. If developers are having to build authorization frameworks, they’re not focusing on things that actually matter to the business.
Learning from the tech giants
While we don’t have the same kinds of mature standards and developer services for authorization that we have for authentication, we do have plenty of examples. Google, Airbnb, Intuit, Netflix, Carta, Uber, Reddit and a whole load of other big firms have written about how they build authorization.
We can distil these examples into a set of patterns – a blueprint for cloud native authorization (as opposed to traditional authorization). Democratizing these patterns is what will underpin future authorization standards and services.
Traditional authorization provided coarse-grained, tenant-level permissions. Enforcing it meant writing if and switch statements inside of the relying party or the API code. Typically, these check whether an access token has a scope or a claim. So, of course, you had to compute which scopes and claims to put in the access token during authentication time.
Such practices are now outmoded and outdated. Instead, cloud native practices are fine-grained policy based in real time.
The three key concepts here are:
- Fine-grained permissions – this means resource-level permissions, so you can be very specific about what a user can do.
- Policy-based permissions – this enables you to extract the authorization logic out of the application, then express it in a domain specific language, with separation of duties.
- Real-time permissions – using the principle of continuous enforcement, this asks an authorization system whether the user has permission to access a particular resource in the moment before granting or denying access.
Cloud native authorization ecosystems
There are two ecosystems in the cloud native authorization world today: policy as code (ABAC) and policy as data (ReBAC). ABAC stands for attribute-based access control, a mostly stateless style of authorization undergirded by a set of specs. ReBAC stands for relationship-based access control.
AuthZEN is the first standards effort to try to unify these different patterns and ecosystems. In the open source world, Topaz tries to combine the best of everything, with an Open Policy Agent (OPA) base and a Google Zanzibar ReBAC directory.
Enforcement points
It’s important to think about how AuthZEN flows plug into existing workflows. The first point is at the API gateway, where the gateway can ask an AuthZEN compliant PDP if a user can execute an HTTP method on a particular HTTP route. If the API gateway passes that along, the backend can then ask a fine-grained authorization question about what that user has permission to do. This is the essence of using AuthZEN for fine-grained gateway-enforced authorization.
Ready to learn more?
Now you’re au fait with using AuthZEN for implementing fine-grained authorization, why not delve deeper into related API governance concepts? Our blog post asking whether the best API strategy is a boring one is a great place to start.
