Authentication is no longer just about users. Agents need credentials, but they do not log in like humans. They run for hours without a session refresh, invoke dozens of tools, and sometimes act on behalf of a user without that user being present. The auth layer built for OAuth flows and cookie-based sessions starts to crack.
Authorizer 2.4 ships with explicit support for AI agents alongside traditional enterprise auth. It is open source, so you can inspect how token issuance, refresh, and revocation differ between user and agent contexts. The release exposes a live case study in dual-mode identity systems: OAuth 2.1 for humans, service accounts and machine-to-machine flows for agents, and agent-to-agent delegation for multi-hop scenarios.
The Identity Problem Agents Create
An agent is not a user, but it still needs an identity. It may need to:
- Call an API on behalf of a user who is offline
- Access an MCP server with scoped permissions
- Delegate a subset of its authority to another agent
- Run for days without a human re-authenticating
Traditional OAuth flows assume a human is present to consent. Session tokens expire in minutes or hours. Refresh tokens are tied to a user session. None of this maps cleanly to an agent that runs autonomously.
Service accounts solve part of the problem, but they often get blanket permissions because scoping is hard. API keys are long-lived and hard to rotate. Agent-to-agent delegation creates privilege escalation risks if not designed carefully.
What Authorizer 2.4 Adds
The release introduces several primitives designed for agent identity:
- OAuth 2.1 support with audience-bound tokens
- Service accounts for machine-to-machine authentication
- Agent-to-agent delegation using OAuth token exchange
- Delegated tokens with actor chains to track who acted on whose behalf
- MCP server integration with OAuth 2.1 protection
- Dynamic Client Registration so agents can register themselves
- Client ID Metadata Documents for agent discovery
On the enterprise side, it still ships SAML, OIDC SSO, SCIM 2.0 provisioning, WebAuthn passkeys, and multi-tenant identity. The architecture has to handle both.
Token Scopes and Session Lifetimes
The core difference between user and agent auth is how you scope permissions and manage token lifetimes.
| Concern | User Auth | Agent Auth |
|---|---|---|
| Session duration | Minutes to hours | Hours to days |
| Refresh flow | User re-authenticates | Automated refresh or long-lived token |
| Permission scope | Broad (user has many roles) | Narrow (agent should only access specific tools) |
| Revocation | Logout or session timeout | Explicit revocation or short-lived delegated tokens |
| Audit trail | User ID in logs | Agent ID + actor chain if delegated |
Authorizer uses audience-bound tokens to limit where a token can be used. A token issued for an MCP server cannot be used to call a different API. This reduces the blast radius if a token leaks.
For agent-to-agent delegation, it uses OAuth token exchange. An agent can request a new token with a narrower scope and pass it to another agent. The actor chain tracks the delegation path, so you can see which agent acted on whose behalf.
Agent-to-Agent Delegation Flow
When one agent needs to delegate authority to another, the flow looks like this:
- Agent A has a token with scope
read:data write:data - Agent A requests a delegated token for Agent B with scope
read:dataonly - Authorizer issues a new token with the narrower scope and records Agent A as the actor
- Agent B uses the delegated token to access the resource
- Logs show Agent B acted on behalf of Agent A
This prevents Agent B from escalating privileges. If Agent A only has read access, Agent B cannot write. If Agent A's token is revoked, all delegated tokens issued from it are also revoked.
MCP Server Integration
Authorizer can expose its MCP surface over Streamable HTTP and protect it with OAuth 2.1. The MCP server becomes an OAuth-protected resource. An agent requests a token with audience set to the MCP endpoint, and that token cannot be used elsewhere.
The flow:
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
&client_id=agent-123
&client_secret=secret
&scope=mcp:read
&audience=https://mcp.example.com
The returned token is bound to the MCP server. If the agent tries to use it against a different API, the request fails. This limits lateral movement if an agent is compromised.
Fine-Grained Authorization with OpenFGA
Authorizer integrates OpenFGA for fine-grained authorization. This is critical when agents need conditional access. For example:
- Agent A can read documents in Project X but not Project Y
- Agent B can write to a database only if the user who delegated authority has write permissions
- Agent C can invoke a tool only during business hours
OpenFGA uses a relationship-based model. You define tuples like user:alice can write document:123 or agent:bot-1 can read project:x. Authorizer checks these tuples before issuing tokens or allowing API calls.
This prevents the "service account with admin access" anti-pattern. Each agent gets exactly the permissions it needs, scoped to the resources it should touch.
Observability and Audit
Every token issuance, refresh, and revocation is logged. For delegated tokens, the actor chain is included. This means you can trace:
- Which agent requested a token
- Which user or agent delegated authority
- What scope was requested
- Which resource was accessed
- When the token was revoked
Logs are structured JSON, so you can pipe them to your observability stack. If an agent misbehaves, you can revoke its tokens and see every action it took.
Deployment Shape
Authorizer is a Go binary. You can run it as a container, deploy it to Kubernetes, or run it as a systemd service. It supports PostgreSQL, MySQL, and SQLite for storage. Redis is optional for session caching.
For production, you need:
- A database for user and agent identity
- Redis for session state (optional but recommended)
- TLS certificates for OAuth endpoints
- A secrets manager for client secrets and signing keys
The MCP server can run in the same process or as a separate service. If you run it separately, you need to configure OAuth audience validation so tokens issued for one service cannot be used for another.
Failure Modes
Token leakage: If an agent's token leaks, an attacker can impersonate the agent. Mitigation: use short-lived tokens and rotate client secrets frequently.
Privilege escalation via delegation: If Agent A delegates to Agent B, and Agent B delegates to Agent C, you can end up with a long delegation chain. Mitigation: limit delegation depth and require explicit approval for multi-hop delegation.
Revocation lag: If you revoke a token, it may still be valid until it expires. Mitigation: use short-lived tokens (minutes, not hours) and check revocation status on every request.
Service account sprawl: If every agent gets a service account, you end up with hundreds of credentials to manage. Mitigation: use dynamic client registration so agents can register themselves, and automate credential rotation.
Technical Verdict
Use Authorizer 2.4 when:
- You need to authenticate both human users and AI agents in the same system
- You want fine-grained authorization with OpenFGA or similar relationship-based models
- You need agent-to-agent delegation with audit trails
- You want OAuth 2.1 protection for MCP servers
- You prefer open source and want to inspect the auth logic
Avoid it when:
- You only have human users and do not need agent identity
- You already have a working auth system and do not want to migrate
- You need a managed service and do not want to run infrastructure
- Your agents do not need delegation or fine-grained permissions
The real value is in the dual-mode design. Most auth systems are built for users or services, not both. Authorizer shows what it takes to handle both in the same codebase: audience-bound tokens, actor chains, dynamic client registration, and tight integration with fine-grained authorization. If you are building a production agent system, you will need to solve these problems. This is one working implementation you can study or deploy.
Top comments (0)