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

Authorizer 2.4.0, an open-source authentication platform, has been released with new support for AI agent authentication, service accounts, and enterprise identity features. The update introduces OAuth 2.1-protected MCP endpoints, OAuth client_credentials for service accounts, and agent-to-agent delegation via token exchange. It also adds SCIM 2.0 provisioning, SAML IdP capabilities, and WebAuthn/passkey support.

Product Hunt https://www.producthunt.com/products/authorizer?launch=authorizer-2 · GitHub https://github.com/authorizerdev/authorizer . Website https://authorizer.dev . Docs https://docs.authorizer.dev 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. The release adds quite a lot, but these are the areas I'm most excited about: You can see the complete list in the 2.4.0 changelog https://github.com/authorizerdev/authorizer/blob/main/CHANGELOG.md 240---2026-08-19 . 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: 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 https://docs.authorizer.dev/core/mcp/ . 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: 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. 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. The other major part of this release is enterprise identity. Authorizer 2.4 adds support for: 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 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 2.4 also adds WebAuthn and passkey support. Users can authenticate using platform authenticators such as: 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. 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. Authorizer 2.4 expands the public API surface across: 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. 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 https://docs.authorizer.dev/getting-started/ . 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: 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 https://github.com/authorizerdev/authorizer/blob/main/CHANGELOG.md 240---2026-08-19 before upgrading. 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: 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. 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/ https://authorizer.dev/ Documentation: https://docs.authorizer.dev/ https://docs.authorizer.dev/ Get started: https://docs.authorizer.dev/getting-started/ https://docs.authorizer.dev/getting-started/ GitHub: https://github.com/authorizerdev/authorizer 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 https://github.com/authorizerdev/authorizer/blob/main/CHANGELOG.md 240---2026-08-19 Release video: https://youtu.be/X0RA-sP8Z5I 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. 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 https://github.com/authorizerdev/authorizer Website: https://authorizer.dev/ https://authorizer.dev/