Source URL: https://simonwillison.net/2024/Oct/14/grant-negotiation-and-authorization-protocol-gnap/#atom-everything
Source: Simon Willison’s Weblog
Title: Grant Negotiation and Authorization Protocol (GNAP)
Feedly Summary: Grant Negotiation and Authorization Protocol (GNAP)
RFC 9635 was published a few days ago. GNAP is effectively OAuth 3 – it’s a newly standardized design for a protocol for delegating authorization so an application can access data on your behalf.
The most interesting difference between GNAP and OAuth 2 is that GNAP no longer requires clients to be registered in advance. With OAuth the client_id and client_secret need to be configured for each application, which means applications need to register with their targets – creating a new application on GitHub or Twitter before implementing the authorization flow, for example.
With GNAP that’s no longer necessary. The protocol allows a client to provide a key as part of the first request to the server which is then used in later stages of the interaction.
GNAP has been brewing for a long time. The IETF working group was chartered in 2020, and two of the example implementations (gnap-client-js and oauth-xyz-nodejs) last saw commits more than four years ago.
Via lobste.rs
Tags: rfc, oauth, security
AI Summary and Description: Yes
Summary: The Grant Negotiation and Authorization Protocol (GNAP), recently published as RFC 9635, represents a significant evolution in authorization methods, offering a more flexible approach than OAuth 2 by eliminating the need for clients to be pre-registered. This advancement has implications for security and compliance professionals by streamlining application interactions and enhancing data access control mechanisms.
Detailed Description:
The introduction of GNAP presents a noteworthy shift in the way applications manage authorization, specifically in how they delegate access to data without the cumbersome requirements of OAuth 2. Here are the key aspects of GNAP:
– **Protocol Overview**:
– GNAP is effectively known as OAuth 3, marking an evolution in delegated authorization protocols.
– It standardizes a method for applications to request data access on behalf of users.
– **Key Difference from OAuth 2**:
– Unlike OAuth 2, GNAP does not require the clients to be registered in advance.
– The traditional OAuth model mandates prior registration, which involves setting up a `client_id` and `client_secret`. This step often complicates the integration process as applications must be individually registered with every service they wish to access, such as GitHub or Twitter.
– **Functionality Enhancement**:
– GNAP simplifies the authorization flow by allowing clients to provide a key in the first request to the server, which will be used in subsequent interactions.
– This approach reduces the initial setup overhead and enhances the flexibility in accessing APIs.
– **Development Context**:
– The GNAP initiative has origins dating back to the IETF working group’s chartering in 2020.
– Despite this recent standardization, development efforts for implementations of GNAP (like gnap-client-js and oauth-xyz-nodejs) date back over four years, indicating a long evolutionary process in its creation.
– **Implications for Security and Compliance**:
– Security professionals may find GNAP particularly relevant as it can lead to less exposure of client credentials, mitigating risks associated with credential management.
– Furthermore, GNAP may streamline compliance efforts by simplifying data access protocols, allowing organizations to maintain tighter control over how data is accessed and by whom.
Overall, GNAP introduces a paradigm shift in authorization protocols that could lead to enhanced security and efficiency in application interactions, making it a significant development for professionals in the domains of AI, cloud, and infrastructure security.