Sessions and API keys

Your Account pages separate browser access from API access. Browser sessions appear under Sessions; programmatic credentials appear under API keys.

Two-factor and recoveryCopy Anchor Link

Open Account → Security. The picture at the top shows what a sign-in to your account has to pass. Under Two-factor, select Enable two-factor, then add the secret to your authenticator app with Copy secret or Open in authenticator. Enter a code in Code from your app and select Enable two-factor again. Store the recovery codes outside the dashboard; each one works once.

Once enrolled, you can Regenerate recovery codes, which ends the previous set at once. Turn off asks for your current password, and is not offered when the installation requires two-factor. An account that has enrolled is asked for a code at every new sign-in, regardless of the JD_REQUIRE_2FA setting. That setting, shown as Require two-factor under Settings → Configuration, controls whether an unenrolled account may sign in.

Review browser sessionsCopy Anchor Link

Open Account → Sessions. The page opens on the session you are using, then draws every session through the network it came in on, with a wire marked amber where a password alone let it in. Other sessions lists the rest with client, network, when each signed in, whether it passed two-factor, and when it was last seen.

Select Sign out on a session you do not recognize, or Sign out other sessions to keep only the one you are using. Changing your password, or a required initial password, signs out every session and returns you to sign-in. Account → Security also lists your sessions with a link to this page.

Session lifetime is configured with JD_SESSION_TTL (absolute limit, default 12h) and JD_SESSION_IDLE_TTL (idle limit, default 60m), or from Sessions under Settings → Configuration. See Configuration.

Create an API keyCopy Anchor Link

1. Open Account → API keys and select New key.
2. Give the key a Name that says where it will live, such as github-actions.
3. Under Can, choose a role. A key can have the same or a narrower role than yours.
4. Under Expires, choose 7 days, 30 days, 90 days (the default), 1 year, or Never.
5. Select Create key and copy the key when it appears. Only its hash is stored; the dashboard cannot show it again. Try it gives a curl command that uses the key.
6. Store it as a secret in the client that will use it.

Send the key as a bearer token (Authorization: Bearer …). If your role is reduced later, or your account is disabled, the key's effective access goes with it. Keys cannot change passwords, create other keys, manage dashboard accounts, or open a Remote Desktop session; those need a browser sign-in.

Manage keysCopy Anchor Link

Where the keys reach draws each active key through its role to the API. Chips narrow the list to keys Used this week, Never used, Unused for 30 days, Expiring soon, or with No expiry, and you can search and sort the list. Revoked and expired keys are kept under Revoked or expired.

From a key's menu:

• Replace key creates a new key with the same name and the same or a narrower role. The previous key keeps working until you select Revoke previous key, so you can update your tool first.
• Revoke key stops the key immediately. Its record stays in history.
• Delete record removes a revoked or expired key from the list. The audit trail is kept. Only administrators can delete records.

Administrators see and can revoke every account's keys; other accounts see their own.

Keys made elsewhereCopy Anchor Link

Two kinds of key are created from Databases → Control center rather than this page, and are listed here with the rest:

• Keys made under MCP server open only the MCP endpoint for AI clients and reach only the databases chosen for them. Giving a key write access to a database needs a limited or admin role. See Databases.
• Keys made under Metrics export can only scrape the database metrics endpoint for Prometheus.

A replacement for either kind is limited the same way as the key it replaces.

Anyone with a key can exercise its effective role through the API, so treat it as a credential. Use a short lifetime for temporary automation and revoke it when that automation ends.