Grant Negotiation and Authorization Protocol (GNAP)

The Grant Negotiation and Authorization Protocol (GNAP) is an Internet Engineering Task Force (IETF) standard (RFC 9635, October 2024) for delegating access to software, designed as a successor to OAuth 2.0 rather than an extension of it. Where OAuth grew a separate grant type or extension for each situation, GNAP starts every request the same way and lets the client and authorization server negotiate how the user is involved, binds every request and token to a key held by the client instead of relying on bearer secrets, and can return information about the user alongside API access, which OAuth leaves to OpenID Connect. It is not wire-compatible with OAuth, so adopting it means new client and server implementations. GNAP supports Redirect-based Interaction, User-code Interaction, Asynchronous Authorization, Software-only Authorization, Refreshing an Expired Access Token, Requesting Subject Information Only and Cross-User Authentication.

GNAP puts information about the user into the core protocol. OAuth was never intended to tell an app who logged in, so many OAuth APIs added their own endpoint that returns profile information for an access token. A GNAP authorization server can return user identifiers and identity assertions in the same response as the access token, or instead of one.

How GNAP Works

A GNAP grant delegates access to a piece of software: to a set of APIs, to information passed directly to the software, or to both.

RFC 9635 defines five roles:

1. Client: the software that requests access. A running copy of it is a client instance, and GNAP identifies the instance by its key rather than by a pre-registered client identifier.
2. Authorization Server (AS): grants delegated access to the client instance, in the form of access tokens and subject information.
3. Resource Server (RS): hosts the APIs and accepts the access tokens the AS issues.
4. Resource Owner (RO): the person or organization that holds the rights to the protected resources and approves the delegation.
5. End user: the person operating the client instance.

The Resource Owner and the end user are separate roles because they need not be the same person. When they are, the flow looks like a familiar consent screen. When they are not, the end user asks for access and the AS reaches the Resource Owner through a separate channel, for example an approver on another device. This is the case GNAP calls Cross-User Authentication, and OAuth handles it only through extensions such as Client-Initiated Backchannel Authentication (CIBA).

The GNAP flow starts when the client instance makes a request to the authorization server. The request says what the client wants, why, and how the end user can be reached. The authorization server answers with a handle for continuing the request and with the interactions it will accept. The client instance runs that interaction with the end user if one is needed, then continues the request with the handle. The authorization server responds with an access token for the resource server.

One Endpoint, and URIs the Server Hands Out

GNAP has no authorization endpoint, no token endpoint, and no authorization code to exchange between them. A client instance needs to know a single address in advance: the AS's grant endpoint, which is also the AS's identifier. Every request, whatever the interaction pattern, is an HTTP POST of a JSON document to that endpoint.

Everything after the first request uses addresses the AS returns:

• Continuation URI: the grant response carries a continue object with a URI and an access token for the negotiation itself. The client instance uses it to poll, to finish after the user interaction, or to modify or cancel the request. The AS may issue a distinct URI for every grant, which keeps the negotiation's state on the server.
• Token management URI: each access token can come with its own manage URI. The client instance rotates the token with a POST and revokes it with a DELETE there, which replaces both the refresh-token grant and the separate revocation endpoint of OAuth.

Every one of these calls is bound to the client instance's key. The client instance proves possession on each request with HTTP Message Signatures, mutual TLS, or a detached or attached JSON Web Signature (JWS), so the continuation and management tokens are useless to anyone who lacks that key. When the interaction runs through a browser redirect, the client instance also checks a hash over values contributed by both sides before it continues, which rejects a forged or injected redirect.

Token introspection is not part of the core protocol. It is defined, together with resource registration, in RFC 9767 (GNAP Resource Server Connections, April 2025) as a service the AS offers to resource servers, and those calls are key-bound too.

Comparison with OAuth 2.0

Appendix A of RFC 9635 names six differences from OAuth 2.0:

1. Consent and authorization flexibility: the client instance and the AS can combine different ways to start and finish a user interaction, and none of them requires a browser. The AS can decide on what the client instance sends, on information from outside parties, and on the user's interaction.
2. Intent registration and inline negotiation: OAuth 2.0 fixes the flow by grant type. A GNAP request always starts the same way, and the next steps are negotiated from what the client can do, the access policy, and the context of the request, over the continuation API described above.
3. Client instances: OAuth 2.0 requires a client registered at the AS under a known client_id. A GNAP client instance can present a key the AS has never seen and use it to protect every later request. Pre-registered clients still work, but the protocol does not need a client identifier.
4. Expanded delegation: access requests are structured objects rather than OAuth 2.0's scope strings. GNAP also defines how to ask for user information separately from API access, and lets the AS and the resource server (RS) agree on the token format.
5. Cryptography-based security: OAuth 2.0 relies on bearer secrets, while GNAP binds every message to a key held by the client instance, for client authentication and for access tokens alike. Extensions can add further proofing methods.
6. Privacy and usable security: GNAP is designed to work with decentralized identity standards and to keep the person in the authorization decision. Extensions define how an RS and an AS communicate, so that resource servers are not tied to a few large authorization servers.

What an Adopter Has to Weigh

GNAP has seen little production deployment, open-source implementations are few, and mainstream identity providers do not offer it. Choosing GNAP today usually means building and operating the authorization server yourself.

There is also no migration path. Because GNAP is not wire-compatible with OAuth, an organization cannot move clients or servers over one at a time: every client, the AS and every RS that validates its tokens has to speak GNAP, and the OAuth stack has to keep running beside it for everything that does not.

Meanwhile OAuth has absorbed much of what GNAP set out to fix. Demonstrating Proof of Possession (DPoP) binds tokens to a client key, Rich Authorization Requests (RFC 9396) give access requests structure beyond scope strings, CIBA decouples the approver from the requesting device, and OAuth 2.1 removes the insecure grants. None of them unifies the model the way GNAP does, but together they close most of the gaps for a team that already runs OAuth.

GNAP fits where there is no OAuth estate to carry along, such as devices without browsers or delegation between parties that cannot pre-register clients with each other.