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/
Top comments (1)
Really impressive evolution of the project. The agent-to-agent delegation + service accounts + fine-grained OpenFGA authorization is a particularly strong combination. Feels like you’re solving the problems that start appearing once AI agents move beyond simple API calls. Congrats on 2.4!