Session tokens

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.)

Default session claims

Below are the default session claims that Clerk generates for you:

azp: authorized party - the Origin header that was included in the original Frontend API request made from the user. Most commonly, it will be the URL of the application (e.g. https://example.com). This claim could be omitted if, for privacy-related reasons, Origin is empty or null.
exp: expiration time - the time after which the token will expire, as a Unix timestamp. Determined using the Token lifetime JWT template setting in the Clerk Dashboard(opens in a new tab).
iat: issued at - the time at which the token was issued, as a Unix timestamp (e.g. 1516239022).
iss: issuer - the Frontend API URL of your instance (e.g. https://clerk.your-site.com if production instance, https://your-site.clerk.accounts.dev if development instance).
nbf: not before - the time before which the token is considered invalid, as a Unix timestamp. Determined using the Allowed Clock Skew JWT template setting in the Clerk Dashboard(opens in a new tab).
sid: session ID - the ID of the current session (e.g. sess_123).
sub: subject - the ID of the current user of the session (e.g. user_123).

The following claims are only included if the user is part of an organization:

org_id: organization ID - the ID of the currently active organization that the user belongs to.
org_slug: organization slug - the slug of the currently active organization that the user belongs to.
org_role: organization role - the role of the user in the currently active organization.
act: actor - will only be included if the user is impersonating another user. See user impersonation for more information.

A Clerk session token payload including all of the default session claims that Clerk provides.

If you want to customize your session token, you can do that by following our guide on customizing session tokens.

Validate session tokens

If you're using the middleware provided by our Clerk SDKs, this is all handled automatically in every request. If you're not using the middleware, you can still use the respective helpers provided by the SDKs to validate the tokens.

To learn how to manually verify a session token, please refer to the manual JWT verification section of our documentation.