Skip to main content
HashnodeAuthorizer BlogAuthorizer Blog

Command Palette

Search for a command to run...

Authorizer 2.4: Open-source auth for AI agents and modern enterprise apps

Updated
•7 min read•View as Markdown
Authorizer 2.4: Open-source auth for AI agents and modern enterprise apps
L
Lakhan Samani

I’m Lakhan Samani from India 🇮🇳. I’m the creator and maintainer of authorizer.dev | Freelance Software Engineer | Prev: Cloud Software Engineer at ArangoDB. I am passionate about building products and developer tools. This website is my internet space, where I write about Building Software | Open Source | Finance and Life.

Product Hunt · GitHub . Website . Docs

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/

#ai#ai-tools#ai-agents#agents#developer-tools#mcp#auth#security#oss#product-hunt

Comments (4)

Join the discussion
Z
zi jie liu1d ago

This is an impressive release — the fact that one self-hostable platform now covers OAuth 2.1, MCP, service accounts, and enterprise SSO/SCIM means teams no longer have to stitch together two or three different identity products (one for users, one for agents, one for enterprise tenancy).

Two things stood out to me:

  1. The audience-bound MCP tokens via RFC 8707. Making sure a token minted for an MCP endpoint can't be replayed as a general-purpose Authorizer credential is exactly the kind of boundary that most platforms get wrong. Security-wise this is the right call.
  2. The SCIM → OpenFGA pipeline. Wiring IdP-provisioned groups straight into ReBAC rules closes the loop between "who's in your org" and "what they can do" — that's the part enterprises actually struggle with.

One practical question: for a team migrating an existing OAuth 2.0/OIDC deployment up to 2.4, how much of the OAuth 2.1 work is config-level vs. breaking token behavior? I noticed the new required --url and --encryption-key flags — I'd love to know how disruptive the upgrade realistically is for someone already in production.

L
Lakhan Samani1d ago

Thanks for reading and appreciating it.

On your migration question.

The OAuth 2.1 work is mostly opt-in, but not entirely.

--oauth2-1-strict defaults to false. Turn it on and /authorize rejects response_type=token and id_token token, and PKCE plain gives way to S256. Leave it off and those flows behave as they do in 2.3. Discovery still advertises implicit and plain while it's off, because the endpoint still accepts them.

What isn't behind the flag: refresh-token reuse detection. Replaying an already-rotated refresh token now revokes that token's family. It's scoped to the lineage rather than the user, so other sessions and login methods stay alive, and there's a grace window for benign double-submits, so a SPA firing two concurrent refreshes won't get logged out. The resource → aud binding is also always on, but only fires if a client sends resource, which existing clients won't.

Treat both new flags as required setup.

--url is enforced: the server exits without it. It closes header-derived host takeover, where the server took its own identity from request headers and an attacker could get a genuine password-reset link pointed at a domain they control.

Set --encryption-key in the same change. It keys secrets at rest: TOTP seeds, and the OTP digests behind email/SMS verification and password reset. Pick a strong random value and then leave it alone. There's no re-encryption path, so changing it later means every enrolled TOTP user has to re-enroll.

L
Lakhan Samani1d ago

Also, may I know which version of Authorizer you are running at the moment? And which deployment method are you using [docker, k8s, railway, etc...]?

P
Puneet Khandelwal1d ago

Securing AI agents properly is going to be the main bottleneck for production rollouts this year. Solid release.

H
Henry Robt2d ago

Open-source authentication for AI agents is an interesting direction, especially as more applications need to handle agent access alongside traditional users. I’m particularly interested in how the new version handles permissions and keeps authentication manageable as these systems become more complex.

L
Lakhan Samani1d ago

Hey thank you, Pls check the demo (https://youtu.be/X0RA-sP8Z5I) + examples (https://github.com/authorizerdev/examples/tree/main/with-agent-permissions)

Can get in touch if you would like to have it configured.

R
Rohan Patel3d ago

Really interesting release. The combination of service accounts, workload identity, token exchange and actor chains addresses a lot of the auth problems that show up once agents start calling other services and acting on behalf of users. The reduced-scope delegation is especially nice.

More from this blog

A

Authorizer Blog

6 posts

Authorizer is an open-source & database independent authentication and authorization solution.