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? 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. who can enter the front door, 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. authorization authorization Types of Authorization 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 . role-based authorization role-based authorization editor commenter 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. viewer viewer 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 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.” LLM chatbots LLM chatbots 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? 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? authorization as a service authorization as a service

This story contains new, firsthand information uncovered by the writer.

Google

Inside Christopher Kelly’s Mission to Redesign Global Finance from the Ground Up

Faisal Al-Monai and the Rise of Tokenized Infrastructure in Saudi Arabia

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

How SaaS Companies are Changing Their Approach to Authorization

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

$INK: The Solana Memecoin with a Vision for Utility

5 Tips for Integrating Security into Development - Part 1

5 Types of Cyber Security and Why It’s Important to be Aware of Them

Application Security Posture Management: An Overview

Balancing Cybersecurity Risk with Technological Innovation: Using Policy as Code

$INK: The Solana Memecoin with a Vision for Utility

5 Tips for Integrating Security into Development - Part 1

5 Types of Cyber Security and Why It’s Important to be Aware of Them

Application Security Posture Management: An Overview

Balancing Cybersecurity Risk with Technological Innovation: Using Policy as Code

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps