Permissions, AI, and Plato’s Ideal API
I decided to talk about API security and spent way too long on making memes again
Welcome Back! Daniel here with another digest 💌
Let’s talk APIs.
For years, developers thought of APIs through the perspective of creating them. This resulted in an eternal quest to achieve Plato’s ideal API through discussing their unification into a single platform in every architecture meeting. Thus projects like GraphQL and OAuth were born, aiming to create one secure and reliable platform for all the product APIs.
Recently, we started thinking about APIs from another perspective as well - we focus on how APIs are consumed, not just how they are created or unified. There are a bunch of reasons for that, which we will get to soon, but I'm here to argue that we need to strike a balance between inbound and outbound API traffic.
Working with the developers in Permit for the past three years, we’ve seen a surge in outbound traffic use, and when it comes to authorization, we see an ever-increasing number of requests for authorization policies regarding API calls to other services. The reason? AI and LLMs.
What Changed?
Users, and thus, their UX, are becoming increasingly sophisticated, and APIs are the engine driving it all. The age of static GUIs is officially over, as modern applications require much more sophisticated, customizable UIs. It's a basic experience every product manager wants to give to their users and a fate that developers are bound to accept.
Unlike other external services, the centralized nature of large models, along with their cloud-native architecture, means that developers consume satellite services like VectorDBs and RAGs from outside. These interfaces consume, on average, six times more API calls than a standard user call. In other words, for every single prompt that a user sends, there are at least 6 calls to external services.
Handling so many API calls creates a new challenge for developers in both inbound and outbound API development. Join us in discussing these challenges in our upcoming event - “**API Development in the AI Era”,** where Akshata Sawant (Dev. Advocate @Salesforce), Sean Keegan (Dev. Advocate @Lunar.dev), and Valentin Despa (Software Developer & Educator) uncover AI's impact on API development.
The New challenges in API development - Pricing and Error Handling
Pricing and error handling are two of the most basic challenges in this new shift. Calling an endless amount of APIs without proper preparations and caching can lead to:
A huge surge in the amount of money we spend while doing so.
A potential disaster of multiple errors returned from APIs that are called in an unstructured form, resulting in countless unhandled errors in your applications.
Thankfully, tools such as lunar.dev are here to help you address these, as well as other issues with their open source.
But you are not here to hear about caching and error handling, right? You're here for the memes to learn about security and authorization. So let’s talk about that.
APIs and Authorization
At Permit, our relationship with API security started back in the early days when we released our guide and plugin for authorizing requests using the Kong API Gateway. There, we used a combination of Permit’s cloud-based policy configuration UI and real-time policy as code. The adoption was immediate, and we have since continued to view API developers as first-class citizens of the Permit platform.
API Authorization is a real challenge. Unlike those who think distinguishing between endpoints is enough to authorize requests, we understand that that is far from reality. Permit’s policy-as-code configuration allows developers to create fine-grained authorization for their API applications. It does so by mapping their URLs to resources or their methods to actions, inheriting fine-grained rules defined within Permit into a reliable and consistent authorization layer.
There are many important best practices for handling authentication and authorization in APIs. We won’t go into all of them here—you can read more about them in this guide we created.
Frontend Only Authorization
As time went by, we learned that developers also want to streamline the same fine-grained authorization to their user's external APIs when they use products such as email and communication providers. So, we created FoAz: Frontend Only Authorization, a protocol and web standard that allows frontend applications to enforce protected access to APIs without requiring a dedicated backend. This allows extending backend policy-as-code configuration to function directly from frontend applications, making third-party APIs secure and efficient.
Streamlining all policies through the entire stack with the same rules propagated for Backend services, DBs, APIs, and the Frontend makes handling security logic, monitoring, and errors much more efficient. Having policy-as-code, decentralized enforcement, and centralized configuration and auditing is definitely the right way to go for securing and authorizing APIs nowadays.
It’s Not Just Us Humans, Though
The challenge of API access doesn't end there though. It’s also crucial that we are able to understand who are the personas we should monitor when handling our security and authorization. API access, as we mentioned - doesn’t end with human users. There are also things like services, internal calls, and many other types of identities to consider. Distinguishing between these is also key to creating better, more reliable methods of decision-making.
In the past month, we’ve seen a new trend become a common issue for developers - access request flows. Most authorization systems today manage access through application or data configuration, with the flow of granting access to new actions and resources requiring further development.
That’s why we decided to release a new set of access request APIs that you can use with or without Permit’s cloud configuration to manage the way you model access request flows in your API applications.
The main takeaway you should have from this feature is that API usage is no longer about writing your own APIs but about how you consume 3rd party ones. In a world full of data and AI, API is the language that drives it all. We encourage you to look at the way you consume APIs, ensure it’s streamlined with your security standards, and that permissions are handled similarly across the stack.
As always, if you survived this far, I welcome you to join our Slack Community,
and if you haven’t done so yet, subscribe to this Substack ❤️
Stay cool 🌈
Daniel