IETF · October 2024
Grant Negotiation and Authorization Protocol
RFC 9635
J. Richer (ed.), F. Imbault
If you are designing greenfield agent auth and can choose a protocol, GNAP is the completed IETF alternative to OAuth. In practice, MCP and most SaaS APIs chose OAuth 2.1, so GNAP is currently adjacent rather than the default.
At a glance
- Problem
- OAuth 2.0's fixed grants, bearer tokens, and redirect-centric interaction cannot cleanly express some delegation and key-bound client cases. GNAP is a different protocol (not an OAuth extension) for negotiating grants, including fine-grained access and identity assertions.
- Identity / authn / authz
- Authorization protocol that can also carry identity assertions. Intentionally not compatible with OAuth 2.0.
Actors
- Client instance
- Authorization server
- Resource owner
- Resource server
When this matters for agents
When this matters for agents: greenfield authorization with key-bound clients and negotiated grants. GNAP is a completed IETF alternative to OAuth (RFC 9635), not wire-compatible. In practice MCP and most SaaS APIs chose OAuth 2.1, so GNAP is adjacent rather than the default. AAuth occupies some of the same 'key-bound HTTP client' space with JWT vocabulary.
Flow in plain language
Client POSTs a grant request including its key and requested access. AS returns a grant response that may include access tokens, interaction instructions, or continuation. Tokens are typically key-bound. Interaction can be redirect, user-code, or other modes.
Key tokens and claims
- GNAP access token
- Often presented with proof of the client key, not as a naked bearer secret.
Implementer notes
Proposed Standard. The GNAP WG has concluded. Parallel existence with OAuth is expected. AAuth occupies some of the same 'key-bound HTTP client' design space but stays closer to HTTP signatures + JWT vocabulary.
Relationship to others
Primary sources
- RFC 9635https://www.rfc-editor.org/rfc/rfc9635.html