Grantex is built on top of OAuth 2.0 — not as a replacement, but as a purpose-built authorization layer for AI agents. This page explains the key differences and when each approach is the right fit.
Side-by-Side Comparison
When to Use OAuth 2.0
OAuth 2.0 is the right choice when:
- You are building human-facing login flows (social login, SSO)
- Your application follows the traditional client → resource server model
- You need broad ecosystem compatibility with existing OAuth providers (Google, GitHub, Okta)
- Agents are not part of your authorization model
Grantex does not replace your identity provider. Use OAuth 2.0 / OIDC for authenticating humans, and Grantex for authorizing what agents can do on their behalf.
When to Use Grantex
Grantex is the right choice when:
- AI agents act on behalf of users and need verifiable, revocable permissions
- Agents delegate to sub-agents and you need to track the delegation chain
- You need a tamper-evident audit trail of every action agents take
- Compliance requirements (SOC 2, HIPAA, GDPR) demand structured evidence of agent activity
- Users need to review and revoke agent permissions through a self-service dashboard
- You want local signature and claim verification without hitting a token
introspection endpoint; JWKS retrieval and caching remain deployment concerns
Using Both Together
A common architecture is:
- OAuth 2.0 / OIDC handles user authentication (login with Google, Okta, etc.)
- Grantex handles agent authorization (what the agent can do, audit trail, revocation)
The Grantex principalId maps to your user’s identity from the OAuth provider. Your app initiates a Grantex authorization request, the user consents, and the agent receives a grant token scoped to exactly what it needs.
Further Reading
Last modified on July 11, 2026
