How to protect your RESTful APIs in Lift with JWT21 Jul 2017
You have a RESTful api as a source of data for your mobile applications or a reactjs/angular/vue/whatever frontend, and you, as a security conscious software engineer (or a good student that follows these security guidelines ) want to protect your precious endpoints from unwanted eyes.
What is JWT
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.
In brief, it’s a string with the following format
where each part is base64url encoded, interactive examples here.
Just rember that the payload is not encrypted and ANYONE that has access to the token can see what’s inside. An attacker can inspect the payload but he can’t tamper with it because it’s signed with a STRONG key that you generated.
My library of choice to encode/decode/verify JWT with Scala is jwt-scala
Building an interceptor with Lift
The api we want to protect is the following
I would like to have a middleware (in Express.js terms, a decorator if you are a Python lover) that intercepts every request that points to a protected resource, decode the JWT inside of the http request’s Authorization header and allow or deny access to the forementioned resource according to the token validity.
How can we do this with Lift?
LiftRules object is where most of the configuration parameters that handles HTTP request and responses reside. It gets initialized during boot.
As the documentation says, this is the place where we tell Lift what resource needs to be protected and how.
Lift doesn’t support Token based authentication out of the box, but thanks to its extensibility we can easily write our own JWT authenticator.
Let the fun begin!
Let’s start with informing Lift that out precious API needs to be protected.
LiftRules.httpAuthProtectedResource, Lift will use the authentication mechanism defined with
In our case
Let’s write it.
First thing to do, in order to tell Lift we are writing an HTTP authentication method, we must extend the
and override the
verified_? partial function, that is the bouncer of our API.
verified_? partial function we need to take the token from the request’s
Authorization header, verify it and decode its payload, if we are interested in the claims inside its stomach.
true, the client is allowed, otherwise a 401 UnauthorizedResponse will be returned.
credentials is a simple function that decodes the JWT with your secret and a given algorithm, you can find the full code at the end of this post.
Now we have an interceptor that can extract a JWT from each request that points to a protected resource, but how can we examine the claims that are inside the token without redoing the work that our interceptor has already done?
It’s simple, we can stick our decoded payload in a
TransientRequestVar, a request variable that has the scope of the current HTTP request.
Now in our api we can access jwtClaims and analyze the JWT payload.
This example is purposefully simple in order to make you better understand the general architecture, a better approach would be deserialize our claims and stick inside the TransientRequestVar not a String but a more suitable and easier to manage data type.
Here below, for your enjoyment, the full source code.
Until next time