JWT templates
Clerk offers the ability to generate JSON Web Tokens (JWTs). Each JWT, or token, represents a user that is currently signed in to your application.
You can control the claims that will go into these tokens by creating custom JWT templates that fit your needs. This enables you to integrate with any third-party services that support authentication with JWTs. An example use case is integrating with a third-party service that is able to consume JWTs, but requires them to be in a particular format.
What is a JWT template?
JWT templates are essentially JSON objects that specify claims to be included in the generated tokens, along with their respective values.
Claim values can be either static or dynamic.
Static values can be any of the regular JSON data types (strings, numbers, booleans, arrays, objects, null) and will be included as-is in the tokens.
Dynamic values, also called shortcodes, are special strings that will be substituted for their actual values when the tokens are generated. Read more in the Shortcodes section.
The following example shows a template that demonstrates both static values and shortcodes. In this example, the values of the aud
and interests
claims are static, and the values of the name
and email
claims are dynamic.
A token generated using the template above would look something like this:
Default claims
In every generated token, there are certain claims that are automatically included and cannot be overridden by templates. Clerk calls these "default claims" and you can learn more about them in the Session tokens reference documentation.
Shortcodes
To include dynamic values in your tokens, you can use shortcodes. Shortcodes are strings that Clerk will replace with the actual values of the corresponding user information when the token is generated.
Metadata in shortcodes
While you can use the {{user.public_metadata}}
or {{user.unsafe_metadata}}
shortcodes to include the complete metadata object in the final token, there might be cases where you only need a specific piece of information.
To keep your tokens lean, you can use the dot notation to access nested fields of the metadata object.
Let's assume the user's public metadata are the following:
To access the interests
array, you would use the shortcode {{user.public_metadata.interests}}
. To access the Home
address, you would use {{user.public_metadata.addresses.Home}}
. See the following example:
Interpolation in shortcodes
Shortcodes can be interpolated inside strings.
For example, you could use interpolation to build the user's full name:
Interpolated shortcodes will always result to string values. For example, if the user does not have a last name associated, the above full name value would be null John
.
Conditional expressions in shortcodes
Conditional expressions use the ||
operator and can be used to substitute a default fallback value for shortcodes that would otherwise result in null
or false
values.
The format of a conditional expression is the following:
The result of a conditional expression is that of the first operand that does not evaluate to null
or false
(also known as "falsy"). If all operands of the expression are falsy, the last operand is returned no matter its value. Therefore, you should always place the default value as the last operand. See the following example:
For this example, in the case that user:
- has verified their phone number
- has not verified their email
- has not provided their first or last name
- does not have any public or unsafe metadata assigned
Then, the output of the generated token would be:
The rules that govern conditional expressions are as follows:
- The result of an expression is either the first operand that is not falsy, or the last operand (no matter its value).
- String literals should use single quotes (
'
). - Only strings, booleans and numbers are permitted as literal (i.e. non-shortcodes) operands.
Create a JWT template
A template consists of the following four properties:
- Template name: a unique identifier for the template. When generating a token, you will have to specify the template to use, using this name. This is a required field.
- Token lifetime: the time in seconds, after which tokens generated with this template will expire. This setting determines the value of the
exp
claim (i.e.exp=current_time+lifetime
). Default is 60 seconds. - Token allowed clock skew: the time in seconds, provided as a leeway to account for clock skews between different servers. This setting determines the value of the
nbf
claim (i.e.nbf=current_time-allowed_clock_skew
). Default is 5 seconds. - Claims: the actual template that's entered into the JSON editor (see screenshot below). A template is essentially a JSON object that describes what the final token claims will look like (shortcodes can be used here). This is a required field.
To create a JWT template:
- In the Clerk Dashboard, navigate to the JWT templates page.
- Select New template.
- You can either select a blank template or choose one of the provided templates.
Generate a JWT
To generate a token using a template, you can use the getToken()
method. See the reference documentation for more information and example usage.
Complete example
The following example demonstrates the full capabilities of JWT templates, including static claim values, dynamic claim values via shortcodes, and Clerk's "default claims".
Given the following user:
- First name:
Maria
- Last name:
Doe
- Profile picture URL:
https://example.com/avatar.jpg
- Clerk ID:
user_abcdef123456789
- Email address (verified):
maria@example.com
- Phone number: (not provided)
- Public metadata:
{ "profile" : {"interests": ["reading", "climbing"] } }
- Unsafe metadata:
{ "foo" : { "bar": 42 } }
And given the following JWT template:
The generated token would look like this:
Feedback
Last updated on