Open Source / Security / Contributed

Beyond OAuth? GNAP for Next Generation Authentication

30 Jul 2021 12:27pm, by Dan Moore

The Grant Negotiation and Authorization Protocol, or GNAP (“g-nap”), is currently being developed in an Internet Engineering Task Force (IETF) working group. Here, I’ll discuss why GNAP is being developed and what its upcoming first release might mean for you.

The proposed new GNAP auth standard grew out of two competing efforts, TxAuth and OAuth.xyz. GNAP will address some of the limitations of OAuth and include new features. Per the GNAP working group charter, the protocol will be used for authorization, API access, user identifiers, and identity assertions.

GNAP is in the discussion and iteration stage and is slated to be released in multiple parts starting sometime in 2021. Here’s the draft protocol.

Why Is GNAP Needed?

The core OAuth specification, RFC 6749, is widely supported and deployed, and it can be extended to support novel use cases, such as a device grant. In addition, you can leverage OAuth2, along with commercial and open source tools, to build a secure auth system. OAuth2 is also easier for clients to implement than protocols like SAML.

However, OAuth2 also has its share of flaws. For instance, to get started using OAuth2, you may need to read more than a dozen RFCs. Even with the recent work on OAuth 2.1, which consolidates some of these RFCs, some use cases require reading through multiple standards documents. Other issues with OAuth 2 include:

• Archaic developer ergonomics, including heavy use of form parameters.
• Bearer tokens come with security risks. (“Proof of possession” solutions like DPOP and MTLS aren’t widely or easily deployed.)
• Discovery of OAuth endpoints is nonstandard and cumbersome.
• The mobile app experience is suboptimal.

GNAP Features and Functionality

Like OAuth 2.1, GNAP aims to address OAuth2 flaws. Below are some GNAP highlights.

Distinct Roles for the Requesting Party and the Resource Owner

In a typical OAuth2 authorization code grant, the owner of a resource can grant delegated access to protected resources. The owner is assumed to be the person who requested the grant. (It’s worth reviewing the roles outlined in the spec.)

However, the party requesting access to protected resources may differ from the resource owner that needs to grant permission. The requesting party drives the resource client, which could be a browser or a device. The protected resources live on the resource server. With GNAP, the entity requesting access can be different from the owner of the resource.

Multiple Access Tokens

With GNAP, a client can ask for multiple access tokens in one grant request (vs. multiple requests). For instance, you could request read privileges on one resource and read and write privileges on another.

The following example from the draft specification is asking for two different tokens for three different resources: photo-api, dolphin-metadata, and walrus-access. These resources can be rich JSON objects like photo-api or simple strings like dolphin-metadata.

Interactions as First-Class Objects

In GNAP, the requesting client declares what kinds of interactions it supports. The authorization server responds to the request with an interaction to be used to communicate with the resource owner or the resource client.

These interactions are defined in the GNAP spec as first-class objects, which provides extension points for future communication. Interactions may include redirecting the browser, opening a deeplink URL in a mobile application or providing a user code to be used elsewhere.

Request Continuations

GNAP provides a grant identifier if the authorization server determines a grant can be continued, unlike OAuth2. In the sample below, the grant identifier, access_token.value, can be presented to the authorization server if the grant needs to be modified or continued after the initial request.

This capability allows a client to modify access privileges up or down if circumstances change.

If the client no longer needs access to protected resources, you can also cancel grants. The authorization server will then revoke tokens associated with this request, which is a departure from OAuth2, where tokens may not be explicitly revoked.

Cryptographic Keys

Cryptographic keys are woven into GNAP at multiple levels. Here’s an excerpt of a sample request from the draft spec:

Built-in Identity Capability

While OAuth2 is an authorization framework with no concept of identity, GNAP includes built-in identity features. If the client knows who the resource owner is, it can present identity claims. On the flip side, a client may request information about the owner of a resource in an initial grant request. If the authorization server determines that the owner has granted permission, the information can be released.

Here’s an example of an authorization server response from the draft:

The key value of the client object is the key that signed the request. Numerous methods (e.g., detached JWS, attached JWS, and mutual TLS) are supported. In addition, the GNAP draft supports bearer tokens, which have been successful in the OAuth2 ecosystem.

Improved Developer Ergonomics

OAuth requires clients to make requests using the application/x-www-form-urlencoded media format. Data is transmitted using form parameters, which can be used by many different clients and most programming languages. However, many modern APIs use application/json as the media format. JSON, though flawed, allows richer object structures than form parameters.

With GNAP, you can collapse many objects into simple strings, you don’t have to use nested structures, and you can identify resources, interactions, and other entities by reference. All references can be static or dynamically generated. Either way, they allow easier communication between the authorization server and the requesting client.

Finally, with GNAP, one endpoint begins all interactions between the requesting client and the authorization server in a streamlined fashion, eliminating the need to consult documentation to find out which endpoints you have to call when.

Next Steps

Justin Richer, who proposed the OAuth.XYZ concept and serves as one of the editors of the GNAP spec, has committed to the following: “GNAP will one day be a formal standard, … and XYZ will transition to being an implementation of that standard.” To that end, one key goal of the IETF working group is to simplify the migration from OAuth 2.0 and OpenID Connect (OIDC} to the new protocol.

That said, you can continue to use OAuth2 and OIDC for standards-based authentication for at least the next two to three years (just be sure to take advantage of OAuth 2.1 security improvements).

As GNAP continues to evolve, consider joining the mailing list and collaborating. Also check out changes in the GitHub repo, where the draft is being edited. And even if you’re a committed OAuth user, you should still review the GNAP spec and see if it fits your use cases better than OAuth, especially as the draft becomes more concrete.

Feature image via Pixabay.