What Is Grant Negotiation and Authorization Protocol (GNAP)?

Grant Negotiation and Authorization Protocol (GNAP) is a next-generation authentication protocol, still in draft form, which might replace OAuth 2.0 in the future. GNAP enables clients to interact with multiple resources, negotiate access, and obtain authorization in flexible ways.

GNAP aims to overcome the limitations of OAuth 2.0. It presents a more flexible, privacy-enhancing solution, with improved security, enhanced developer experience, and greater interoperability, addressing the evolving needs of modern applications and services.

Here is a link to the current draft of the GNAP protocol specification.

Learn more in our detailed guide to authentication vs authorization 

In this article:

Limitations of OAuth 2.0 and the Need for GNAP

OAuth 2.0, introduced in 2012 as RFC 6749, has been a foundational protocol in securing authorization processes. Its extensive support and deployment, adaptability to new use cases, and relatively straightforward implementation without requiring deep security knowledge have made OAuth 2.0 popular.

Despite these advantages, OAuth 2.0 has several notable limitations that have prompted the development of the GNAP protocol: 

• Reliance on browser redirects: This can limit the utility of OAuth 2.0 in scenarios where a browser is not the primary client, such as with certain mobile and desktop applications. This can result in suboptimal user experiences, as the authentication process may require a system browser, disrupting the flow of native applications.
• Developer experience: OAuth 2.0’s developer experience is considered old-fashioned by current standards. The protocol heavily uses form parameters, which are less flexible compared to modern JSON structures. Additionally, OAuth does not provide a discovery process for OAuth endpoints as part of the protocol.
• Security: The common issuance of bearer tokens presents risks as these tokens can be used by anyone who obtains them, making them susceptible to interception and misuse. Although “proof of possession” mechanisms like DPOP and MTLS exist, these features are not widely adopted due to their complexity and the difficulty of deployment.
• Complexity: OAuth 2.0 includes multiple specifications that can be daunting for those new to the protocol. The need to understand various RFCs adds to the steep learning curve and complicates the development process.

GNAP aims to rectify these issues. It enhances the developer experience by using more modern data structures for communication and simplifies the discovery of service endpoints. It intends to reduce the reliance on bearer tokens, decreasing security risks. GNAP also aims to improve the user experience, particularly on mobile platforms, by reducing the need to disrupt native application flows for authentication purposes.

Related Content: Read Our Magic Links Guide

How GNAP Works 

Let’s review the key roles in GNAP, the primary elements that participate in the authentication process, and the actual authentication flow.

Roles in GNAP

End User

The end user is the individual who uses a client application and owns the data or resources that the application wants to access. GNAP gives the user the ability to grant or deny access to your data. The user also has the ability to specify the level and duration of access. This ensures that users have full control over their personal data and can protect it from unauthorized access.

Authorization Server

The authorization server issues access tokens to the client after successful authorization. It plays a central role in the GNAP process, evaluating the client’s request, interacting with the end user for consent, and issuing tokens as per their authorization. The server provides a secure and reliable mechanism for authorization, ensuring that only legitimate clients get access to the user’s data.

Resource Owner

The resource owner is the entity that has the authority to grant access to a particular resource. This could be the end user, or a third party that manages the resource on their behalf. The resource owner’s role is to ensure that the resource is accessed in a secure and controlled manner. With GNAP, resource owners can efficiently manage access to their resources, enhancing security and privacy.

Resource Server

The resource server is the server hosting the resources that the client wants to access. Once the client has obtained an access token from the authorization server, it can use this token to access resources on the resource server. The resource server validates the token and provides the requested resources if the token is valid. This ensures that only authorized clients can access the resources.

Client

The client is the application or service that wants to access the end-user’s data or resources. It could be a web app, a mobile app, or any other type of application. The client initiates the GNAP process by sending a request to the authorization server, seeking authorization to access the data. The client’s role is to provide a seamless and secure experience for the end user, while accessing their data according to permissions they have granted.

GNAP Elements

Subject

The subject is the entity whose attributes are being evaluated for granting access. This could be a person, a device, or a software application. The subject initiates the GNAP process by sending a request to the GNAP server to access a specific resource. The subject’s request includes their attributes and the rights they wish to exercise on the desired resource.

Subject information

Subject information refers to the data that identifies and describes the subject. This includes the subject’s identity and the associated security credentials. This information allows the GNAP server to authenticate the subject and determine their authorization level.

Attribute

An attribute is a piece of data that characterizes the subject. This could be the subject’s role in an organization, their geographic location, the device they are using, etc. Attributes are used by the GNAP server to make informed decisions about the subject’s access rights.

Right

This is the specific action that the subject is authorized to perform on a resource. This could include activities like reading, writing, updating, or deleting data. The rights that a subject can exercise on a resource are determined by the GNAP server based on the subject’s attributes and the policies defined for the resource.

Access token

An access token is a digital key issued by the GNAP server to the subject after successful authentication and authorization. The access token encapsulates the subject’s approved rights and is used by the subject to access the protected resource. The token’s validity is typically time-bound and may be revoked by the GNAP server at any time.

Protected resource

A protected resource is the digital asset that the subject wants to access. This could be a database, a file, a web service, etc. The protected resource relies on the GNAP server to authenticate and authorize access requests, ensuring that only authorized subjects can access and manipulate the resource.

Grant

A grant in GNAP is the permission given to the subject to exercise specific rights on a resource. The grant is based on the subject’s attributes and the resource’s policies. The GNAP server issues a grant after validating the subject’s request and verifies the grant each time the subject uses their access token.

Privileges

These are the rights that the subject has been granted on the resource. Privileges define what the subject can do with the resource – read it, write to it, update it, delete it, etc. They are encapsulated in the access token and are enforced by the protected resource.

Related Content: Read Our Fido2 Guide

GNAP Authentication Flow

Below is the official authentication flow as defined in the GNAP IETF Draft. Refer to the document for the full process flow. Below we provide a simplified explanation of the key steps in the process.

Client’s Request to the Authorization Server

The GNAP flow begins with the client making a request to the authorization server. This request contains information about the client’s desired access, the client’s capabilities, and the client’s interaction preferences. The authorization server then responds with an interaction handle, a continuation URI, and an access token, if immediate access is granted.

Interaction Steps Between the End-User and authorization server

Following the client’s request, the end-user interacts with the authorization server. This interaction can take various forms, depending on the client’s and the end-user’s preferences. The end-user may be asked to authenticate, provide consent, or complete other tasks as needed. Once the interaction is complete, the end-user is directed to the continuation URI.

Token Issuance by the authorization server

After the end-user completes the interaction, the authorization server issues a token. This token represents the granted rights and is bound to the client instance. The client can then use this token to access the desired resources.

Client’s Access to the RS Using the Token

The client uses the issued token to access the RS. The RS validates the token, checks the associated rights, and serves the request if the token is valid and the rights are sufficient. This step completes the GNAP flow, allowing the client to securely access and interact with the desired resources.

GNAP vs. OAuth 2.0: Key Differences 

Flexibility and Interaction

Unlike OAuth 2.0, which has a rigid flow and limited interaction capabilities, GNAP offers more dynamic negotiation options and interaction models. This means you can tailor the protocol to fit your specific needs, including complex multi-party scenarios and non-browser based applications. In addition, GNAP’s interaction options are not limited to redirections, making it more user-friendly and versatile.

Customer Identification

With OAuth 2.0, customer identification could be challenging. OAuth 2.0 relied heavily on bearer tokens which, while convenient, didn’t provide robust identification. GNAP, on the other hand, supports various types of tokens, including reference and structured tokens. These tokens can be bound to a specific client instance, making customer identification more secure and reliable.

Rich Token Introspection

The token introspection feature of GNAP is richer and more detailed than that of OAuth 2.0. GNAP’s token introspection allows for a deeper understanding of a token’s status and associated data. This feature provides the ability to retrieve metadata about the token, such as its issuance time, expiration date, and scope of access. This in-depth information can be useful for managing and securing applications.

Security Concerns

GNAP addresses several concerns that were previously problematic in OAuth 2.0. For instance, GNAP minimizes bearer token usage, reducing the risk of token leakage. It provides flexible interaction options, allowing for better user consent and privacy. By offering a more secure framework, GNAP reassures users and developers about the security of their data and applications.

Using OAuth with Frontegg

Frontegg’s end-to-end and self-served authentication infrastructure is based on JSON Web Tokens. Our JWTs have been designed to adhere to the highest security standards. Therefore, our user management solution is also fully compliant with the OAuth protocol, along with OpenID Connect 1.0 (OIDC) as well. We cover all important bases that are required in the modern SaaS space. 

START FOR FREE