Authorization is a critical, yet invisible, part of most applications. Authorization defines who has access to which data. Using a physical security analogy, if authentication is about who can enter the front door, authorization is about who has keys to which rooms.
Historically, development teams built authorization logic into their application code. But building and maintaining authorization logic has become mind-numbing work, and over time, no one wants to touch the code in fear of giving the wrong person access to sensitive information. This issue is amplified by the explosion of LLM chatbots, which need to train using a lot of data, not all of which should be exposed to the end user.
Recently a new crop of developer tools has emerged to address this critical component of software development. Like Twilio has done for SMS or Stripe for payments, vendors like Oso aim to solve authorization so that developers can focus on their core app.
Types of Authorization
There are several common authorization patterns. Typically, organizations start with role-based authorization (or RBAC), where users have defined roles that determine the data that they can access. Using Google Docs as an example, a given document might have an editor, commenter, or viewer.
Sounds simple, right? Let’s extend the Google Docs example. Let’s say a user creates an entire folder of documents. If you have viewer access to the folder, you should have viewer access to all of the underlying documents. Now we need to implement relationship-based access control (or ReBAC), which means that not only do you need roles, but you also need to organize permissions based on the relationship between resources.
You then may want to introduce further requirements, such as defining public vs private documents, time-bound access (this person can have editor access to the document until close-of-business), or conditional access (sensitive HR documents cannot be accessed, even if your role would allow it otherwise). This type of authorization is called attribute-based authorization.
Securing LLM Chatbots
In addition to these traditional authorization patterns, the explosion of LLM chatbots introduces new ways to interact with data—as well as new challenges. The flexibility and scale of LLMs make it harder to ensure that you don’t leak sensitive data. In order to be accurate, these models need to train on a large corpus of data. When returning answers, however, it’s imperative that only end users only see the data that they’re supposed to see. For example, imagine an employee asking an internal chatbot, “Please summarize the outcomes of the executive staff meeting for the last 6 months.”
Below is an example of the data flow for an authorized RAG chatbot, which incorporates permission checks prior to returning an answer to the end user:
Who is using authorization as a service?
New vendors offering authorization as a service enable companies to deliver fine-grained access controls, such as role-based access control (RBAC), relationship-based access control (ReBAC), and attribute-based access control (ABAC), as well as emerging use cases to secure LLM chatbots. An increasing number of organizations are now using authorization-as-a-service to secure their applications. Will your organization be next?
