This article is aimed at those looking for an overview of the draft IETF GNAP core protocol.
It’s going to be very broad brushstrokes, but hopefully enough to give you a flavour of what GNAP is, and specifically how it differs to OAuth2.0.
The reason that the piece is written through a comparative lens is that the authorization paradigm most engineers (myself included) are familiar with is OAuth2.0. Therefore it can provide the base we build from.
This means you’ll need a fairly solid understanding of OAuth2.0, luckily this can be gleaned from an excellent article here. We’ll also be referencing some of its extensions, but won’t refer to them as separate entities.
Why GNAP?
GNAP was introduced to solve the same problems as OAuth2.0 and OIDC, and does so in a similar way. It still requests delegated authorization from a resource owner via a grant, and still utilises an authorization server.
I can immediately hear you asking ‘why do we need it then?’ which is incredibly fair. However, GNAP does address some important concerns, which we’ll explore next.
Consent and authorization flexibility
In OAuth2.0 we generally assume we have access to a web-browser. Additionally how our flow works is dictated by the grant type at the start. For example when we start the device authorisation grant for limited input devices (e.g. smart TVs) we make a request to a certain endpoint. Once we’ve begun this grant we can’t swap to another.