OAuth 2.0 swept the web in 2012, as the authentication upgrade that allow users to securely log in to websites and many sign-on systems, ranging from AWS’s Cognito to Okta, implemented OAuth.

While OAuth enables you to “authenticate with Google” and other providers with a completely different website or application, but OAuth was designed around browsers, and assumes that the originator making the request can handle an HTTP redirect.

The browser focus is rather a stumbling block for apps or the “Internet of Things”, coupled with the fact that OAuth requires that you post form parameters instead of JSON. Hence, there is a new proposal to replace OAuth with GNAP, though the specification is still in its early stages, its features goes further than even OAuth 2.1.

How GNAP addresses some limitations of OAuth with new features



GNAP is intended to further the idea that security is a really exciting field, and it addresses some limitations of OAuth and spices it with some new features.



Instead of relying on HTTP parameters, GNAP allows you to use JSON, and application endpoints are quite discoverable. You don't have to support redirects or use any of the various hacks around it. And GNAP proposes to support new security features as follows:

  • Multi-Access Tokens: Allows clients to authenticate to several resources at once, as both user and administrator.
  • Asynchronous & Application URL Launch: Are different authentication paths that allow authentication without a redirect. GNAP enables applications to also authenticate to third-party resources with no direct access.
  • Request Continuations: Allow clients to negotiate stuff like redirects or other details during the authentication process and a client is also allowed to negotiate for additional privileges or access tokens.


Additionally, there is the Sender Constraint Tokens which are add-ons to OAuth 2 for functionality called DPOP and MTLS, as GNAP build this directly into the protocol. For instance, if a token was dropped (or intercepted), it would not matter because the bearer would not have the password.

How to get Started with Using GNAP



If you want to start using GNAP right away, or you're interested in collaborating with other users, you can fork one of the prototypes from the existing proposal on GitHub.

Albeit, the authors aim to release GNAP in 2022, which is still a long way off. But, the GNAP working group is actively looking for collaborators, which you can join via the mail list and offer your expertise.

OAuth Replacement: GNAP addresses some limitations of OAuth with new features

OAuth 2.0 swept the web in 2012, as the authentication upgrade that allow users to securely log in to websites and many sign-on systems, ranging from AWS’s Cognito to Okta, implemented OAuth.

While OAuth enables you to “authenticate with Google” and other providers with a completely different website or application, but OAuth was designed around browsers, and assumes that the originator making the request can handle an HTTP redirect.

The browser focus is rather a stumbling block for apps or the “Internet of Things”, coupled with the fact that OAuth requires that you post form parameters instead of JSON. Hence, there is a new proposal to replace OAuth with GNAP, though the specification is still in its early stages, its features goes further than even OAuth 2.1.

How GNAP addresses some limitations of OAuth with new features



GNAP is intended to further the idea that security is a really exciting field, and it addresses some limitations of OAuth and spices it with some new features.



Instead of relying on HTTP parameters, GNAP allows you to use JSON, and application endpoints are quite discoverable. You don't have to support redirects or use any of the various hacks around it. And GNAP proposes to support new security features as follows:

  • Multi-Access Tokens: Allows clients to authenticate to several resources at once, as both user and administrator.
  • Asynchronous & Application URL Launch: Are different authentication paths that allow authentication without a redirect. GNAP enables applications to also authenticate to third-party resources with no direct access.
  • Request Continuations: Allow clients to negotiate stuff like redirects or other details during the authentication process and a client is also allowed to negotiate for additional privileges or access tokens.


Additionally, there is the Sender Constraint Tokens which are add-ons to OAuth 2 for functionality called DPOP and MTLS, as GNAP build this directly into the protocol. For instance, if a token was dropped (or intercepted), it would not matter because the bearer would not have the password.

How to get Started with Using GNAP



If you want to start using GNAP right away, or you're interested in collaborating with other users, you can fork one of the prototypes from the existing proposal on GitHub.

Albeit, the authors aim to release GNAP in 2022, which is still a long way off. But, the GNAP working group is actively looking for collaborators, which you can join via the mail list and offer your expertise.

No comments