Authentication is a trickier subject today than it was 10 years ago. There are hundreds of potential strategies for securing APIs and ensuring that a user is, in fact, who they say they are. When building or refactoring APIs, developers have to decide what authentication strategy makes sense for their particular product use case. This can be daunting, as choosing the wrong approach can lead to difficulties down the road including data breaches, trouble building integrations, and user experience limitations that plague product development. At BoltSource, we’ve had great success leveraging the generic and flexible stateless authentication mechanism provided by JSON Web Tokens. Most of our engineers have 5+ years of battle hardened experience using JWTs full-stack in large-scale consumer and enterprise grade systems. In this post, we’re going to share what we’ve learned about building APIs with JWTs.
What is a JWT?
JSON Web Token (JWT) is an open standard (RFC 7519), popularized by the good folks at Auth0, that defines a compact and self-contained way for securely transmitting information between parties with an encoded JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret or a public/private key pair.
In this tutorial we are going to focus on using secrets, but know that public/private key pairs are an especially useful tool here if you plan to have a centralized authentication service that generates JWTs with a private key and want other services to be able to verify JWTs using the paired public key in order to avoid sharing secrets between services.
JWTs are encoded into a URI-friendly string, which can be passed between client and server via the header, body, or URI parameters of a request/response. In its compact form, JSON Web Token strings consist of three sections delimited by dots (.). Below is a description of each section, in order:
- A header, which is a Base64Url encoded object that typically contains the type (JWT) and the signing algorithm (HMAC, SHA256, RSA, etc)
- A payload, which is a Base64Url encoded object that_typically_contains a set of claims and additional data about the user (such as the user’s primary key).
- A signature, which is encoded by passing the secret, the encoded header, and the encoded payload into the signing algorithm and then encoding the output as Base64Url.
The output is three Base64-URL strings delimited by dots that can be easily passed between client and server in HTML and HTTP environments, while being more compact than alternatives such as SAML. If you want to see this process in action, check out the JWT.io Debugger where you can generate and inspect JWTs and their data
JWTs are used in the same manner as most other token-based authentication strategies. During the login flow, the client (such as a web application) sends the server a set of credentials. The server then looks up the performs checks against the credentials via business logic. If the credentials are accepted, the server generates a JSON Web Token and sends it back to the client as part of the response. The client, optionally storing the token in a cookie, attaches the token to all subsequent authenticated requests to the server, usually via an Authentication header using the Bearer schema. However, the server implementation can be constructed in such a way that it accepts the JWT being passed in other ways, such as in the request body or in the URI.
#node #json #jwt #security #web-development
