These docs are for AuthRocket 1. Looking for AuthRocket 2 docs?

Settings: Sessions & JWT

These settings affect how AuthRocket manages sessions and login tokens for authenticated users. AuthRocket uses JWT-style login tokens and they may be decoded by any compatible JWT library. Libraries are available in nearly every language.

JWT signing algorithm

AuthRocket supports JWT login tokens that are signed with one of two algorithms: HS256 and RS256.

The default is HS256 and is recommended in most cases. They are quite a bit smaller and computationally faster. HS256 tokens use a symmetric signing key. This key must be kept secret at all times.

In contrast, RS256 use an asymmetric signing key. While these are both larger and computationally slower, they do have one distinct advantage in that the key can be shared publicly without compromising your security. If you require the ability to validate JWT tokens inside a native client app or in the browser, or to allow 3rd-parties to validate your tokens, then use RS256.

JWT secret / JWT key

The JWT secret or JWT key is used to decode JWT tokens. If the signing algorithm (above) is RS256 (it will also have “PUBLIC KEY” inside the key itself), then it is publicly shareable.

Otherwise, it is a secret key and must not be exposed in a client app or web browser; these must be used server-side only. The JWT secret is only shown if the viewing user has permission to view it (“Manage realm” permissions).

This is only shown if the viewing user has permission to view it (“Manage realm” permissions).

Included token data

By default, login tokens include fields about the session and the authenticated user. You may optionally add fields about all memberships, orgs, and custom attributes. Since orgs are connected to users via memberships, orgs requires memberships too.

When enabled, custom attributes will be included for the user as well as memberships and orgs if those are also enabled.

Including lots of token data can make the tokens quite large. This sometimes triggers parsing errors, particularly when the token is passed as part of the URL. Most of the time these can be worked around. See our discussion of Token size.

Read more about our use of JWT tokens.


Managed sessions track the ongoing validity of the session on AuthRocket’s side. This enables powerful functionality like enforced logouts (including across apps in SSO configurations), listing all active sessions, and more. It does add a little bit of overhead though. Additionally, users may have a maximum of 10 active sessions.

Unmanaged sessions have none of this, but as noted, can perform slightly faster. Unmanaged sessions can still be validated by using server-side JWT validation.

Use this setting to toggle between managed and unmanaged sessions (for human users only–API-type users are always unmanaged).

Session length

Login sessions can be set to last anything from very short periods (for more sensitive apps) to very long periods, or even set to not expire at all (unmanaged sessions only).

There are two settings: one for human users and one for API-type users.

The dropdown in the UI provides a number of convenient default options. If none of those are suitable, you can set any arbitrary value via the API with the Realm.session_minutes field (human users) and Realm.api_key_minutes field (API-type users).

Questions? Find a Typo? Get in touch.