Manual JWT Verification
A guide to manually validate your session tokens
Introduction
When a user is authenticated in your application, a short-lived session token is generated by Clerk.js that depicts the fact and it's sent to your backend. Your backend will typically want to validate that the session token is valid (i.e. that it comes from Clerk, that it hasn't expired etc.)
If you're using the middlewares provided by our Clerk SDKs, this is all handled automatically in every request. If you're not using the middlewares, you can still use the respective helpers provided by the SDKs to validate the tokens. That is all good, but if an SDK does not exist for the application's programming language, you will have to manually validate these tokens.
This guide provides instructions on how to do exactly that; manually validate the Clerk session tokens that your backend receives.
Overview
Your Clerk-generated session tokens are essentially JWTs which are signed using your instance's private key and can be verified using your instance's public key. Depending on your architecture, these tokens will be in your backend requests either via a cookie named __session
or via the Authorization
header.
For every request, you must validate its token to make sure it hasn't expired and it is authentic (i.e. no malicious user tried to tamper it). If these validations pass, then it means that the user is authenticated to your application and you should consider them signed in.
Instructions
By following the steps below, you can validate the session token on your own and make sure that the user session is still active and valid.
- Retrieve the session token from either
__session
cookie or from theAuthorization
header - Get your instance's Public Key. There are 3 ways to do it:
- Via the Backend API in JSON Web Key Set (JWKS) format at the following endpoint
https://api.clerk.dev/v1/jwks
(If there is more than one JWKS, decode your session token, get the tokenkid
from the header part and construct the respective public key) - Via the Frontend API in JSON Web Key Set (JWKS) format at the following endpoint
https://<YOUR_FRONTEND_API>/.well-known/jwks.json
(If there is more than one JWKS, decode your session token, get the tokenkid
from the header part and construct the respective public key) - If you are planning to use Clerk on a Serverless/Edge Runtime where JWKs caching is challenging, you can use the instance Public Key as an environment variable. The key can be found in
Dashboard > API Keys > JWT Verification Key
. Note that the JWT Verification key is not in PEM format, the header and footer are missing, in order to be shorter and single-line for easier setup.
- Via the Backend API in JSON Web Key Set (JWKS) format at the following endpoint
- Use the above Public Key to verify the token's signature
- Validate that the token is not expired, by checking the
exp
andnbf
claims - If the
azp
claim exists, validate that equals any of your known Origins that are permitted to generate those tokens. This is an extra security check that we highly recommend that you do
Steps (3) and (4) should better be done by existing JWT libraries of your favourite language
If the above process is successful, it means that the user is signed in to your application and you can consider him authenticated. You can also retrieve the session ID and user ID out of the token's claims.
Using the JWT Verification Key
As mentioned above, your JWT Verification Key is not in a PEM format. This is to avoid having to use "multiline environment variables" which are difficult to use in many systems/environments. In order to get a properly formatted public key from you will need to transform it slightly.
Transform steps:
- Split the JWT Verification Key into chunks of 64 characters
- Join the chunks separated with a newline character
\n
- Append, and prepend the appropriate header and footer
- Header:
-----BEGIN PUBLIC KEY-----\n
- Footer:
\n-----END PUBLIC KEY-----
- Header:
The output should look something like the following:
1-----BEGIN PUBLIC KEY-----2MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXbBOUbeOfvxtIUDNDBb377J66FTRpJhB/o3OwQhjYAgcJ1XLEenzUKiczq8b1zJ/xcqdWT4TYamFthcdv/sD4zmS13DbHHlkYVfE6hG1sG0r/ahCWORi3F2WZT9u7rjwli3A647e5eHdy3qD/tvcB5E42UmRmcL2mbedaQiVy2i5U5qlIXI6YAC+BYiVdw5YOrGNQWzoAHX8kBmwjMWQTQ64AKvSZHYf3Mtd0ni0LTmZD8WXvGbQr4Ia5caZfyGzFkPPbNFSXzyT9yJZOB281HP7hMUlECYRmPlHloBZBArowkQRk5rlLKu+tdpUp0B7hJcHTAcgn7qZuecIZX4EmVWM8bwIDAQAB9-----END PUBLIC KEY-----
The code below, is an example implementation written in javascript:
1const splitPem = process.env.CLERK_JWT_VERIFICATION_KEY.match(/.{1,64}/g);2const publicKey = "-----BEGIN PUBLIC KEY-----\n" + splitPem.join("\n") + "\n-----END PUBLIC KEY-----"
Putting it all together
1import type { NextApiRequest, NextApiResponse } from 'next';2import Cookies from 'cookies';3import jwt from 'jsonwebtoken';45export default async function (req: NextApiRequest, res: NextApiResponse) {6const splitPem = process.env.CLERK_JWT_VERIFICATION_KEY.match(/.{1,64}/g);7const publicKey =8'-----BEGIN PUBLIC KEY-----\n' +9splitPem.join('\n') +10'\n-----END PUBLIC KEY-----';1112const cookies = new Cookies(req, res);13const sessToken = cookies.get('__session');14if (!sessToken) {15res.status(401).json({ error: 'not signed in' });16}1718try {19var decoded = jwt.verify(sessToken, publicKey);20} catch (error) {21res.status(400).json({22error: 'Invalid Token'23});24return;25}2627res.status(200).json({ sessToken: decoded });28}
1import Cookies from 'cookies';2import jwt from 'jsonwebtoken';34export default async function (req, res) {5const splitPem = process.env.CLERK_JWT_VERIFICATION_KEY.match(/.{1,64}/g);6const publicKey =7'-----BEGIN PUBLIC KEY-----\n' +8splitPem.join('\n') +9'\n-----END PUBLIC KEY-----';1011const cookies = new Cookies(req, res);12const sessToken = cookies.get('__session');13if (!sessToken) {14res.status(401).json({ error: 'not signed in' });15}1617try {18var decoded = jwt.verify(sessToken, publicKey);19} catch (error) {20res.status(400).json({21error: 'Invalid Token'22});23return;24}2526res.status(200).json({ sessToken: decoded });27}