The year was 2012, and a revised security protocol called OAuth 2 swept the web, allowing users to use security providers to easily log in to websites. Many single sign-on systems, from AWS’s Cognito to Okta, implement OAuth. OAuth is what enables you to “authenticate with Google” or other providers to a completely different website or application.
It works like a beer festival. You go to a desk and authenticate with your ID (and some money), and they give you tokens. From there, you go to each beer tent and exchange a token for a beer. The individual brewer does not need to check your ID or ask if you paid. They just take the token and hand you a beer. OAuth works the same way, but with websites instead of beers.
Sadly, OAuth is the best beer festival 2020 has to offer.
I spoke with Dan Moore from FusionAuth about OAuth and a proposed replacement called GNAP—which is likely pronounced without the G as “nap.” The pronunciation furthers the idea that security is a really exciting field. GNAP addresses some limitations of OAuth and spices it with new features.
Why replace, or rather augment, OAuth? OAuth was designed around browsers. It assumes that the originator making the request can handle an HTTP redirect. This web browser focus is a stumbling block for mobile apps or any kind of “thing” on the “Internet of Things.” Additionally, OAuth parties like it is 2007 and requires that you post form parameters instead of JSON.
The OAuth spec was vague in some places, and the world changed since 2012. There is a slew of RFCs and BCPs, essentially add-on specs that you have to implement for more capabilities, better security, and general compatibility. A separate effort called OAuth 2.1 hopes to collapse some of these addons into a more coherent single spec. For some of the motivations for OAuth 2.1, see Lee McGovern from Okta’s post “How Many RFCs Does it Take to Change a Lightbulb.” OAuth 2.1, unlike GNAP, is just an incremental release with no new significant changes besides combining the stack of specifications into a single specification.
The GNAP specification is still in its early stages. GNAP’s authors plan to go further than OAuth 2.1 and change the nature of the protocol itself. Instead of using HTTP parameters, you can use JSON. Application endpoints are discoverable. You do not have to support redirects (or the various hacks around that). Moore refers to these changes under the delightful term, “developer ergonomics.”
A key goal of GNAP is the separation of who requests the resources (RQ) and who owns the resources (RO).
IETF GNAP also proposes to support new security features such as:
- Asynchronous and Application URL Launch. These are different authentication paths that allow the client to authenticate without a redirect. GNAP also enables applications to authenticate to third-party resources to which the resource server and authorization server have no direct access.
- Request Continuations. These allow clients to negotiate things like redirects or other authentication details during the authentication process. They also allow a client to negotiate for additional privileges or access tokens.
- Multiple Access Tokens. These allow clients to authenticate to many resources at once, for instance, as both user and administrator.
- Sender Constraint Tokens. While there are add-ons to OAuth 2 for this functionality called DPOP and MTLS, GNAP would build this directly into the protocol. Return to our beer tent example. What if we also had to whisper a password into the seller’s ear while handing them the token? If our token was dropped (or intercepted), it would not matter because the bearer would not have the password.
- And GNAP causes the ghost of Kerberos to scream.
Sound good? Can you start using GNAP today? If you are interested in collaborating, you can fork one of the prototypes that went into the existing proposal on GitHub.
According to Moore, the authors are aiming to release GNAP in 2022. Since each day in 2020 is like a week in a typical year, GNAP is a long way off. However, the GNAP working group is looking for collaborators, and you can join the mail list and offer your feedback and expertise. I guess you cannot fix everything in the world, but you can at least help fix OAuth.