npm init
. This will setup your package.json
file.
You can leave the default settings or change them as you see fit.
Our sample’s package.json
looks like the following:
expressJwtSecret
we can generate a secret provider that will provide the right signing key to express-jwt
based on the kid
in the header. For more information refer to the node-jwks-rsa GitHub repository.req.body
as something easier to interface with.For more information and several alternatives refer to the body-parser GitHub repository.server.js
file. Your code needs to:
node server
and make an HTTP POST request to localhost:8080/timesheets
. You should see a JSON response with the message This is the POST /timesheets endpoint
.
So now we have our endpoint but anyone can call it. Continue to the next paragraph to see how we can fix this.
jwt
function, provided by the express-jwt middleware, and the jwks-rsa
to retrieve our secret. The libraries do the following:
express-jwt
will decode the token and pass the request, the header and the payload to jwksRsa.expressJwtSecret
.jwks-rsa
will then download all signing keys from the JWKS endpoint and see if a one of the signing keys matches the kid
in the header of the JWT. If none of the signing keys match the incoming kid
, an error will be thrown. If we have a match, we will pass the right signing key to express-jwt
.express-jwt
will the continue its own logic to validate the signature of the token, the expiration, audience
and the issuer
.localhost:8080/timesheets
we should get the error message Missing or invalid token
(which is perfectly fine since we didn’t send an Access Token in our request).
In order to test the working scenario as well we need to:
Authorization
header to our request with the value Bearer ACCESS_TOKEN
(where ACCESS_TOKEN
is the value of the token we retrieved in the first step).scope
) to use our endpoint in order to create a timesheet. In particular we want to ensure that the token has the correct scope, which is batch:upload
.
In order to do this we will make use of the express-jwt-authz
Node.js package, so go ahead and add that to your project:
jwtAuthz(...)
to your middleware to ensure that the JWT contain a particular scope in order to execute a particular endpoint.
We will add an additional dependency. The express-jwt-authz library, which is used in conjunction with express-jwt, validates the JWT and ensures it bears the correct permissions to call the desired endpoint. For more information refer to the express-jwt-authz GitHub repository.
This is our sample implementation (some code is omitted for brevity):
403
. You can test this by removing this scope from your API.
express-jwt
middleware which is used to validate the JWT, also sets the req.auth
with the information contained in the JWT. If you want to use the sub
claim to identify the user uniquely, you can simply use req.auth.sub
.
In the case of the timesheets application however, we want to use the email address of the user as the unique identifier.
The first thing we need to do is to write a rule which will add the email address of the user to the Access Token. Go to the Rules section of the Dashboard and click on the Create Rule button.
You can give the rule a descriptive name, for example Add email to Access Token
, and then use the following code for the rule:
namespace
is used to ensure the claim has a unique name and does not clash with the names of any of the standard OIDC claims. However, Auth0 supports namespaced and non-namespaced custom claims. For more info on custom claims, see Create Custom Claims.
Next, inside your API, you can retrieve the value of the claim from req.auth
, and use that as the unique user identity which you can associate with timesheet entries.