A Crash Course in the Grant Negotiation and Authorization Protocol (GNAP)

<h1>Audience</h1> This article is aimed at those looking for an overview of the <a href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol" rel="noopener ugc nofollow" target="_blank">draft IETF GNAP core protocol</a>. 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 <a href="https://medium.com/@jc1175/a-crash-course-in-oauth-c4c00e418db0" rel="noopener">here</a>. We’ll also be referencing some of its extensions, but won’t refer to them as separate entities. <h2>Why GNAP?</h2> <a href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#name-introduction" rel="noopener ugc nofollow" target="_blank">GNAP was introduced to solve the same problems as OAuth2.0 and OIDC</a>, 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, <a href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#appendix-B-2.1.1" rel="noopener ugc nofollow" target="_blank">GNAP does address some important concerns</a>, which we’ll explore next. <a href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol#appendix-B-2.1.1" rel="noopener ugc nofollow" target="_blank">Consent and authorization flexibility</a> 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 <a href="https://datatracker.ietf.org/doc/html/rfc8628" rel="noopener ugc nofollow" target="_blank">device authorisation grant</a> 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. On top of this, the user employing the client is the same user who will approve access (i.e. the authorization server won’t send something out to another party requiring authorization on their behalf). GNAP aims to address all of this. It is less tied to the web-browser, more flexible, and allows for the case where the user employing the client needs to request authorization from another party (as we’ll see in the ‘cross-user authentication’ section). <a href="https://jc1175.medium.com/a-crash-course-in-the-grant-negotiation-and-authorization-protocol-gnap-9cc30ed21ce5">Click Here</a>