Authorizer 2.4.0 is out.

I've been working on Authorizer for a few years, and 2.4 is one of the biggest releases I've worked on so far.

A big part of this release came from a simple problem:

Authentication is no longer only about users.

Applications also need to deal with services, workloads, organizations, and AI agents.

At the same time, enterprise applications still need things like SSO, SCIM, passkeys, multi-tenant identity, and fine-grained authorization.

With 2.4, I wanted Authorizer to handle both sides of that problem.

What's new in Authorizer 2.4?

The release adds quite a lot, but these are the areas I'm most excited about:

• OAuth 2.1 and MCP support
• Service accounts and machine-to-machine authentication
• Agent-to-agent delegation
• Workload identity
• WebAuthn and passkeys
• SAML and OIDC SSO
• SCIM 2.0 user and group provisioning
• Organizations and multi-tenant identity
• Fine-grained authorization with OpenFGA
• GraphQL, REST, gRPC, and MCP APIs
• A redesigned MFA flow
• OAuth and security hardening

You can see the complete list in the 2.4.0 changelog.

Authentication for AI agents

One of the biggest areas I worked on in this release is authentication for AI agents.

An agent isn't a user, but it still needs an identity.

It may need to call an API, access an MCP server, act on behalf of a user, or communicate with another agent.

That creates a different set of authentication and authorization problems.

Authorizer 2.4 adds support for:

• OAuth 2.1
• Remote MCP servers
• Dynamic Client Registration
• Client ID Metadata Documents
• Service accounts
• Machine-to-machine authentication
• Agent-to-agent delegation
• OAuth token exchange
• Delegated tokens with actor chains

For MCP, Authorizer can expose its MCP surface over Streamable HTTP and protect it with OAuth 2.1.

Tokens are audience-bound to the MCP endpoint, so a token intended for the MCP server isn't treated as a general-purpose Authorizer credential.

Learn more in the MCP documentation.

Service accounts and workload identity

Not every request comes from a person.

Background workers, services, CI jobs, Kubernetes workloads, and other systems need to authenticate too.

Authorizer 2.4 adds first-class service accounts using the OAuth client_credentials flow.

Service accounts can also use workload identity mechanisms including:

• RFC 7523 JWT bearer assertions
• SPIFFE JWT-SVID
• Kubernetes TokenReview

This means workloads don't necessarily have to depend on long-lived static credentials.

Service accounts also become first-class subjects in the authorization layer, which makes it possible to apply authorization rules to machines in much the same way as users.

Agent-to-agent delegation

Another interesting part of 2.4 is agent-to-agent delegation.

An agent can act on behalf of a user without simply receiving the user's full access.

Authorizer uses OAuth token exchange (RFC 8693) to create delegated tokens.

The resulting token carries information about the actor chain and can have a reduced scope.

For example:

User
  ↓
Agent A
  ↓
Agent B

Each step can have fewer permissions than the previous one.

The effective scope is limited by the permissions available to the user, the agent, and the requested scope.

This makes delegation more explicit than passing around a user's original access token.

Enterprise SSO

The other major part of this release is enterprise identity.

Authorizer 2.4 adds support for:

• SAML 2.0
• OIDC federation
• SAML Identity Provider
• SAML Service Provider
• Verified email domains
• Home realm discovery
• Organization-level SSO configuration
• SCIM 2.0 provisioning

Organizations can configure their own identity providers and manage users within their own tenant.

For example, an organization can connect its existing identity provider and provision users through SCIM rather than requiring administrators to manage every user manually.

Authorizer can also act as a SAML IdP when other SaaS applications need to authenticate against it.

SCIM 2.0

SCIM is another area that became important for enterprise deployments.

Authorizer 2.4 supports SCIM 2.0 user provisioning as well as SCIM groups.

This allows identity providers such as Okta and Entra to provision and deprovision users.

Groups can also be connected to authorization rules through OpenFGA.

That gives you a path from:

Identity Provider
      ↓
     SCIM
      ↓
   Users / Groups
      ↓
    OpenFGA
      ↓
Application permissions

Passkeys and WebAuthn

2.4 also adds WebAuthn and passkey support.

Users can authenticate using platform authenticators such as:

• Touch ID
• Face ID
• Windows Hello

It also supports FIDO2 security keys, usernameless discoverable login, and using passkeys as an MFA factor.

The MFA flow itself was also redesigned in this release.

Fine-grained authorization with OpenFGA

Authentication tells you who someone is.

Authorization answers a different question:

What are they allowed to do?

Authorizer 2.4 uses an embedded OpenFGA-based relationship authorization engine.

This lets you model relationships such as:

user:lakhan
    ↓ member
organization:acme
    ↓ owns
project:authorizer

And then make permission checks based on those relationships.

The FGA engine can run embedded or use an external OpenFGA store, depending on the deployment.

More ways to use the API

Authorizer 2.4 expands the public API surface across:

• GraphQL
• REST
• gRPC
• MCP

The goal here is fairly simple: use the interface that makes sense for your application without having to build a separate authentication layer around it.

The underlying service layer is shared across these transports.

Built for self-hosting

Authorizer remains open source and self-hostable.

You can run it yourself and keep control over your authentication and authorization infrastructure.

If you want to try it, the easiest place to start is the Getting Started guide.

Security was a big part of this release too

A lot of the work in 2.4 isn't visible in a product screenshot.

There are several OAuth and security hardening changes in this release, including:

• SSRF-hardened external fetches
• OAuth 2.1 hardening
• RFC 8707 audience binding for MCP
• Stricter client authentication
• Improved token validation
• Workload identity validation
• Rate-limit fail-closed option
• OIDC discovery and JWKS caching
• A separate encryption key for secrets stored at rest

There are also breaking configuration changes in 2.4, including the requirement to provide a canonical --url and, for certain JWT configurations, an explicit --encryption-key.

If you're upgrading an existing deployment, I strongly recommend reading the 2.4.0 changelog before upgrading.

Why I built this

I've spent a lot of time working on authentication over the years.

The problems have changed.

A few years ago, the main question was usually:

How do I authenticate users in my application?

Today, that is only part of the problem.

You may also have:

• APIs talking to other APIs
• background services
• Kubernetes workloads
• enterprise identity providers
• multiple organizations
• AI agents
• agents acting on behalf of users
• MCP servers
• fine-grained permissions

I wanted Authorizer to be useful for these cases without requiring developers to assemble a different identity product for every one of them.

That's a big reason why 2.4 ended up being such a large release.

Try Authorizer 2.4

If you're building a SaaS product, API, enterprise application, or AI-enabled application, I'd love for you to try it.

Website: https://authorizer.dev/

Documentation: https://docs.authorizer.dev/

Get started: https://docs.authorizer.dev/getting-started/

GitHub: https://github.com/authorizerdev/authorizer

What's new in 2.4.0: https://github.com/authorizerdev/authorizer/blob/main/CHANGELOG.md#240---2026-08-19

Release video: https://youtu.be/X0RA-sP8Z5I

If you try it, I'd genuinely like to hear what works, what doesn't, and what you'd like to see next.

About Authorizer

Authorizer is an open-source authentication and authorization platform for modern applications.

It provides authentication, authorization, enterprise SSO, passkeys, SCIM, organizations, machine-to-machine authentication, and APIs across GraphQL, REST, gRPC, and MCP.

GitHub: https://github.com/authorizerdev/authorizer

Website: https://authorizer.dev/

TL;DR

• Vector search ignores your permission model: an engineer can ask your RAG assistant about board-level financials and get them, because semantically close = retrieved, and a restricted chunk in the prompt can't be un-read.

• Fix it with a pre-filter: Authorizer's embedded OpenFGA answers list_permissions with the user's token, and that allow-list becomes a Qdrant must payload filter — forbidden chunks are never scored.

• Revocation is one tuple deletion, effective on the next question. No re-indexing, no re-login.

• Verified live: 63 tests green (including a dedicated fail-closed permission suite), official quay.io/authorizer/authorizer:2.3.0 image, real grant/revoke cycle. Run it: docker compose up -d && python scripts/fga_seed.py && python scripts/fga_demo.py --llm.

There's a quiet security regression happening in almost every company shipping AI features right now.

You spent years getting access control right. Row-level security in Postgres. Folder permissions in Drive. Channel membership in Slack. Then someone embedded all of it into a vector database, pointed an LLM at it, and called it a knowledge assistant.

The assistant doesn't know about your permission model. Similarity search returns whatever is semantically close — the intern asking "how do raises work?" gets chunks of the compensation memo, because cosine similarity has no concept of "need to know." And once a restricted chunk lands in the prompt, it's over: you cannot redact what the model has already read.

The common fix is a post-filter: run the vector search first, then check each result against your permission system and drop what the user shouldn't see. Most off-the-shelf "permission-aware retriever" wrappers work exactly this way. It's better than nothing, but the forbidden chunks were still scored, fetched, and held in your application's memory before being discarded — and if 3 of your top-4 results get dropped, your agent answers from a starved context. When the checks run against a hosted authorization service, you also pay a network round trip per result, and your company's entire who-can-see-what graph lives on someone else's infrastructure.

We built it the other way around — as a pre-filter, fully self-hosted, on an open-source stack — and shipped it as a runnable demo. The demo's knowledge base belongs to a fictional ACME Corp and holds four documents: a public onboarding guide, an engineering tech-stack doc, a finance-only Q4 financial report, and a security policy. Picture the most relatable version of the leak: an engineer asking the assistant about company financials. Same question, two users, different answers. Here's the actual output:

👤 alice@example.com   (engineering)   may view: onboarding_guide.txt, tech_stack.txt
   ❓ What was our Q4 revenue and cash runway?
   💬 I don't have enough information in the knowledge base to answer this question.

👤 carol@example.com   (finance)       may view: financial_report.txt, onboarding_guide.txt
   ❓ What was our Q4 revenue and cash runway?
   💬 The Q4 revenue for ACME Corp was \(14.2M, and the monthly cash burn is \)1.1M —
      a 26-month runway at current burn.

Alice isn't being told "access denied." ACME's financial report simply does not exist in her world — it was never a search candidate, never retrieved, never in the prompt. The model cannot leak what it never saw. Carol, who's on the finance team, gets the number.

Here's the use case at a glance — the same question, the two outcomes, and the open-source stack underneath:

The stack — open source end to end

Every piece runs on your hardware, and each one earns its place:

• Authorizer (≥ v2.3.0) — open-source authentication and authorization in one Go binary. It embeds an OpenFGA engine (the open-source implementation of Google's Zanzibar relationship-based access control), so the server that issues your users' tokens also answers "can this user view this document?" — in-process, no extra service to deploy.

• Qdrant — the vector database whose payload filters make true pre-filtering possible: a must condition is evaluated during the HNSW vector search, not bolted on after. This single feature is what lets the permission boundary live inside the retrieval step. Its built-in dashboard (/dashboard) also lets you inspect exactly which chunks and payloads exist.

• FastEmbed — local ONNX embeddings (BAAI/bge-small-en-v1.5, 384 dimensions, ~25 MB). No embedding API, no per-token costs, works offline after the first download.

• Ollama — the local LLM (llama3.2 in the demo). Prompts containing your internal documents never leave the machine.

• Gradio — the demo's web UI, now with a login row so each person chats as themselves.

Nothing in this chain phones home: not the documents, not the tokens, not the permission graph, not the prompts.

docker compose up -d              # Qdrant + Authorizer (quay.io/authorizer/authorizer:2.3.0)
python scripts/fga_seed.py        # demo users, authorization model, grants
python scripts/fga_demo.py --llm  # watch two users get different answers

Permissions are relationships, not roles

The document side of the authorization model is six lines of OpenFGA DSL:

type document
  relations
    define owner: [user]
    define viewer: [user, user:*, team#member]
    define blocked: [user]
    define can_view: (viewer or owner) but not blocked

Access is granted by writing facts, not code:

user:*                    viewer   document:onboarding_guide.txt   # public
team:engineering#member   viewer   document:tech_stack.txt         # a team, not a user list
team:finance#member       viewer   document:financial_report.txt   # finance only
team:security#member      viewer   document:security_policy.txt
user:<alice>              member   team:engineering
user:<carol>              member   team:finance

That team:finance#member viewer tuple is the whole ballgame for our example: Alice is a member of team:engineering, not team:finance, so she has no path to document:financial_report.txt. Carol does.

Notice what's not here: no changes to the ingestion pipeline, no per-user collections, no ACL columns bolted onto chunk metadata. Each Qdrant chunk already carries its source filename in the payload — the FGA object is simply document:<that filename>. The payload you already have is the join key.

How does it work? The architecture

Under the hood it's one Python app process talking to three local servers. The important part is the order: the permission check happens before the vector search, so off-limits files are never even embedded into the candidate set.

It comes down to two API calls.

One: before searching, ask Authorizer what this user may see — authenticated with the user's own token:

allowed = authz.allowed_documents(user_token)
# GraphQL: list_permissions(relation: "can_view", object_type: "document")
# Alice (engineering) → ["onboarding_guide.txt", "tech_stack.txt"]   # no financial_report

Two: hand that allow-list to Qdrant as a must condition:

FieldCondition(key="source", match=MatchAny(any=allowed))

Qdrant evaluates the condition during HNSW traversal. Forbidden vectors are never candidates — top-k stays full of the best chunks the user may see, instead of being decimated by after-the-fact redaction.

And because the permission call carries the end user's JWT, Authorizer pins the subject server-side. An explicit "check as someone else" is rejected unless the caller is a super-admin. A fully prompt-injected agent has nothing to escalate with: it asks as Alice, it gets Alice's answer — and Alice can't see finance.

Fail closed, or don't bother

The demo treats every ambiguous state as deny:

• Authorizer unreachable → AuthorizationError, not an unrestricted search.

• Authorization configured but no token supplied → error, not a silent bypass.

• Permission list truncated → refuse, a partial allow-list is not the full one.

• Empty allow-list → refusal answer without ever calling the LLM.

• And after generation, the cited sources are batch re-checked with check_permissions — a grant revoked mid-request raises instead of leaking.

That last list is about 30 lines of code total. It's the difference between a security feature and a security theater feature.

Revocation that actually revokes

The demo's second act grants Bob engineering access — one tuple write — and his very next question retrieves the tech-stack doc. Then it deletes the tuple:

⚡ Granting: bob → member → team:engineering
👤 bob   may view: onboarding_guide.txt, tech_stack.txt    ← immediately

⚡ Revoking the same tuple
👤 bob   may view: onboarding_guide.txt                    ← immediately

No re-embedding. No re-indexing. No re-login. No "takes effect after the nightly sync." Permissions live in tuples, not in the vector index — offboarding a contractor is one _fga_delete_tuples call, and their next question is denied.

What we verified (and what we'd tell you anyway)

This isn't a whiteboard architecture. The demo ships a dedicated fail-closed permission suite (authz client, Qdrant pre-filter semantics, pipeline enforcement) — the full suite is 63 tests, all green — and the whole flow ran live against the official quay.io/authorizer/authorizer:2.3.0 image, including the grant/revocation cycle above.

Honest notes from the build: list_permissions caps at 1,000 objects (the client fails closed on truncation — model access via teams/folders to stay under it); contextual tuples work on checks but not on the list call; and Authorizer's CSRF guard requires an Origin header on server-side POSTs — your reverse proxy or HTTP client needs to send one.

FAQ

Do I need to re-index Qdrant when permissions change?

No. Permissions live in OpenFGA relationship tuples, not in the vector index. Granting access is one _fga_write_tuples call and revoking is one _fga_delete_tuples call — both take effect on the user's very next question. The embeddings, payloads, and collections in Qdrant are never touched.

What happens if Authorizer is unreachable mid-request?

The pipeline fails closed: the permission client raises an error and the user gets no documents — never all documents. The same applies to expired tokens, missing tokens when authorization is enabled, and truncated permission lists. Treating every ambiguous state as "deny" is roughly 30 lines of code in the demo.

Can a prompt-injected agent bypass the filter?

No. The agent calls Authorizer with the end user's own JWT, and the server pins the permission subject from that token — a "check as someone else" parameter is rejected unless the caller is a super-admin. A hijacked agent holds no privileged credential, so it asks as the user and gets the user's answer: denied.

Does this work with LangChain or LlamaIndex?

The demo's permission calls go through the official authorizer-py SDK — login, check_permissions, list_permissions, all typed and fail-closed. There's no dedicated LangChain/LlamaIndex retriever wrapper yet, but the pattern (allow-list → vector-store metadata filter) ports directly to any retriever that supports pre-search filtering — Qdrant's LangChain and LlamaIndex integrations both expose payload filters. The demo's authz.py is the thin glue, and packaging it as a reusable retriever is the obvious next step.

What are the current limits?

list_permissions caps at 1,000 objects per call (the client fails closed on truncation — model access via teams or folders to stay under it). Contextual tuples work on check_permissions but not on the list call, parameterized CEL conditions aren't exposed through the API, and the embedded FGA engine needs a SQL datastore.

Run the demo yourself, in four steps

Step 1 — Start the tools. One command brings up Qdrant and Authorizer (with its embedded OpenFGA engine):

docker compose up -d        # Qdrant on :6333, Authorizer on :8080

Step 2 — Seed ACME's users and permissions. The seed script is idempotent: it signs up the three demo users, installs the authorization model, and writes the relationship tuples — all skipped on re-runs.

python scripts/fga_seed.py
# ✓ Created users alice (engineering), carol (finance), bob (new hire)
# ✓ Installed authorization model
# ✓ Granted: team:finance#member viewer document:financial_report.txt …

This produces ACME's access matrix:

Step 3 — Log in. Launch the UI; it asks you to log in first (it can't answer anything until it knows who you are), with the demo accounts shown right on the page:

python src/app.py --authorizer http://localhost:8080

Log in as alice@example.com (engineering) or carol@example.com (finance), password Demo@Pass123. The login screen is shown first — the credentials are verified against Authorizer, and the chat only appears once you're authenticated.

Step 4 — Ask the same question as different people. Ask "What was our Q4 revenue?" as Alice and you get "I don't have enough information" — the financial report was never retrieved. Ask Carol and she gets ACME's $14.2M. Prefer the terminal? python scripts/fga_demo.py --llm runs the whole comparison, including a live grant-and-revoke.

Links

• Demo: https://github.com/lakhansamani/qdrant-rag-llm-example/tree/main

• FGA guide (models, patterns, full DSL reference): https://docs.authorizer.dev/core/fga-guide

• Authorization API: https://docs.authorizer.dev/core/graphql-api

• GitHub: https://github.com/authorizerdev/authorizer ⭐

• SDKs: Python (used in this demo) · Go · JavaScript — check_permissions / list_permissions Ship in all three.

• Discord: https://discord.gg/3Jse9RtS

Your agents are only as trustworthy as the boundaries you give them. Give them real ones — on your own hardware.

You can get started in 3 easy steps

Step 1: Deploy Authorizer Instance

Step 2: Setup the instance using built-in dashboard

Step 3: Integrate the universal login page with your application

Let’s have a look at the amazing set of features 🚀

Secure Session Management

Authorizer follows the best practices in the auth space and gives you secure session management using

• HTTP only cookies (Recommended for web)
• Authorization Code Flow (Recommended for mobile applications)
• OAuth2 with Open ID compatible APIs

Multiple Auth Recipes

Authorizer comes with an amazing set of auth recipes out of the box, which includes major social media logins, magic link login, and basic authentication. You can easily configure this recipe using the dashboard that is shipped with every instance of Authorizer.

Myriad Database Support

Authorizer now supports 11+ databases including major SQL, NoSQL, and GraphDB with the motive Your Data Your Control. Bring your database and it will just add a few tables/collections in your database to generate auth layer for you.

Role Base Access Control

Secure your APIs and UI depending on various roles for your application. You can easily configure the user roles in your dashboard and have them validated in the JWT tokens.

Integrate / Implement

Every instance of Authorizer comes with a universal login page which you can integrate in your application with a few lines of code. This page is rendered based on the configuration you have in the dashboard. Still, if you need to build the custom UI then we have React SDK and JS SDK which you can leverage.

Custom Emails

Now you can send emails for various Authorizer events with your own design and messaging. You can also give personal touch to this emails with the help of dynamic variables that will be replaced before sending emails

Multi-factor Authentication

Now you can add one more layer of security by enabling multi-factor authentication which will send one time passwords (OTP) via emails to users and after entering that password only user will be able to access your application. This feature is enabled for basic authentication at the moment.

Listen to events

Most advanced feature of Authorizer. You can now listen to various Authorizer events in your APIs with the help of webhooks and take further actions if required

With all this amazing set of features, you can deploy Authorizer instances on your infrastructure using Docker, Kubernetes, or Binaries. Also, you can use the one-click deployment options that we offer to get started quickly 🚀

I hope you like it and give it a try. You can support our work by contributing to the project, sending Github sponsorship, buying us coffee, or giving us a star on Github. For more information check out the links below.

Website: https://authorizer.dev

Docs: https://docs.authorizer.dev

Github: https://github.com/authorizerdev/authorizer

React SDK: https://github.com/authorizerdev/authorizer-react

Javascript SDK: https://github.com/authorizerdev/authorizer-js

Youtube: https://youtube.com/playlist?list=PLSQGbUjHc6bpaAgCiQPzNxiUPr7SkDAFR

Examples: https://github.com/authorizerdev/examples/

Discord: https://discord.gg/Zv2D5h6kkK

Github Sponsorship: https://github.com/sponsors/authorizerdev/

Buy me Coffee: https://www.buymeacoffee.com/lakhansamani