Access & Identity
What this screen is for
Access & Identity is where your deployment decides who may sign in and how long it keeps trusting them: how often the key that signs its tokens is rotated, the windows an activation or password-reset link stays usable, the browser origins allowed to call the platform, when a run of failed logins locks an account, and how long a remembered session lives. The sidebar entry opens this group; the five entries under it — JWT, Account Lifecycle, Lockout & Anti-Abuse, CORS and Sessions & Cookies — each open one section of what is described below.
Four further entries sit in this group and are not settings at all: Identity Federation and Workload Identity Federation are subsystems with their own screens, their own lifecycle and their own pages here, Passkey metadata holds the FIDO metadata file passkey attestation is verified against, and Authentication policy decides how platform administrators sign in and which sign-in methods every tenant may admit.
What must exist first
You reach this surface in the platform context. Every request behind it is refused unless your token carries the platform tenant, and the refusal says only "Forbidden" — it never tells you which tenant or which permission was wrong.
- The permission to read the platform configuration fills these lists. Without it the shell still admits you if you hold an audit permission or one that reaches a self-contained leaf, and the sections below then say the configuration is not available to you rather than showing you an empty table.
- The permission to change the platform configuration turns Edit on. Without it every row is readable and none is editable.
- One row — the refresh-token SameSite attribute — is classified DANGEROUS and additionally needs the dangerous-change permission. The screen asks you to type the setting key before Save becomes usable, and the platform refuses the write without that second permission whether or not you typed it.
Decisions you make here
Each row shows its effective value, where that value came from, and one badge per service the value reaches. A row the platform will not let you change carries a lock and a reason. Beside each row is what happens when you change it: Live — applies instantly to all instances, Restart required, Read-only diagnostic, or Owned by the deployment — set in the environment, applied on redeploy. Read that line before you read the value: it is the difference between a change that takes effect now and one that waits for a redeploy you have to perform.
JWT
Eleven rows, and exactly one decision. Ten are the keys of the account-activation pair and of the four service-to-service pairs, held as deployment secrets, shown masked and never revealed by this screen or by the platform behind it. The key that signs user access tokens is not among them: it is not a deployment secret, and you see it — and rotate or revoke it — on Token signing keys, under Cryptography & Trust.
The decision is the token signing-key rotation period: the age, in days, at which the platform rotates the key that signs user access tokens. It defaults to 90 and accepts 1 to 365.
A rotation never signs anyone out: the next key is published before it starts signing, and the retired key stays published until every token it signed has expired, so the period is only a limit on how long one key signs — and so on how much a leaked key could forge before it is replaced. A longer period changes nothing for users. Do not shorten it to answer a suspected compromise; revoke the key instead. The change is live and takes effect at the next scheduled check.
Account Lifecycle
Three decisions, all live, plus two read-only rows reporting the public base URLs that activation and reset links are built from.
Password history depth is how many previous password hashes are kept to stop reuse. It defaults to 5 and accepts 3 to 24. Lowering it is destructive and cannot be undone: the surplus history is pruned at each user's next password change, so the reuse check permanently loses passwords it could previously reject, and restoring the old number does not bring them back. Raising it costs a few rows per user.
Activation-token validity (hours, default 24, range 1 to 168) and password-reset-token validity (minutes, default 60, range 5 to 1440) are both the same judgement: how long a link that lands in a mailbox stays redeemable by whoever can read that mailbox. A lapsed activation token cannot be revived — the user needs a fresh invitation. The reset value also drives the single-use record that stops a link being replayed and the validity stated in the reset e-mail, so an unreasonably small number expires links before they can be opened and weakens replay protection at the same time.
Lockout & Anti-Abuse
Four values that only make sense read together, all live. Failed sign-ins are counted per authenticator: a password or a TOTP code per client network, a recovery code or a passkey per account. A lock of one never refuses another, so wrong passwords never lock out a passkey or an identity provider.
Maximum attempts (default 5, range 1 to 100) is how many failures of one authenticator lock it. Account maximum attempts (default 20, range 5 to 100) counts wrong passwords and TOTP codes from networks the person has not signed in from in the last 30 days; its lock refuses both from those networks only. Window (default 15 minutes, range 1 to 1440) is the trailing period over which failures are counted. Duration (default 15 minutes, range 1 to 1440) is how long a lock lasts.
Shorten the window too far and a patient attacker never reaches the ceiling, because older failures keep ageing out and the lockout effectively stops firing. Lengthen it and unrelated failures from hours earlier accumulate into a lockout for a legitimate user. A locked authenticator cannot be cleared by using it correctly, because it is refused while the lock exists: the person signs in with another one, or waits — so a long duration is measured in support tickets.
Every lock is recorded in the audit trail. When the lock notices are switched on, the person is e-mailed at most once per lock duration for an authenticator lock (the warning before a lock counts as that one), and once when the account maximum locks.
CORS
Nothing here is editable from this screen, and that is the point of reading it. One row reports whether the applications handle CORS at all. The other two — the allowed browser origins and the response headers exposed to browser JavaScript — are owned by the deployment: you change them in the environment and they apply on redeploy. The screen names the variable for each.
Enumerate every origin that must reach the platform, exactly. Credentialed CORS forbids wildcards, so a value containing one — or an empty value — makes the services refuse to start rather than fall back to something permissive. Omitting a legitimate origin fails the other way: everything starts cleanly and the console breaks in the browser only. Note also what does not enforce this: the edge proxy neither reads these values nor emits a CORS header. Each application's own filter does, which is why a change waits for those services to restart.
Sessions & Cookies
Seven rows. Five bound every signed-in session, and they are live; one sets how recent a sign-in must be for sensitive actions; the last behaves differently on purpose.
The absolute session lifetime (minutes, default 720, range 60 to 1440) is the longest a session lasts from the original sign-in; no refresh, tenant switch or Remember Me extends it. The inactivity timeout (default 30, range 15 to 60) ends a session nobody has used for that long.
Remember Me (on by default) lets a sign-in keep its session across browser restarts, with its own inactivity timeout (default 720, range 15 to 1440), never beyond the absolute lifetime. The refresh reuse grace (seconds, default 10, range 0 to 60) tolerates two tabs refreshing at once; an old token presented later ends the whole session. A value outside its range is refused.
The reauthentication window (seconds, default 300, range 60 to 900) is how recent a person's last confirmation of identity must be for the sensitive actions: changing their own credentials, identity providers, domains, federated links or authentication posture, repairing a person's account or appointing a tenant administrator from the platform, authorising support access, deciding a quorum request, and entering a tenant as a platform operator. An older one asks the person to confirm their identity again. It is live, and no value turns the requirement off.
The refresh-token SameSite attribute is the DANGEROUS row, and it needs a restart. It accepts Lax, None or Strict, defaults to Lax, and falls back to Lax if the override is ever withdrawn. None lets the browser attach the refresh cookie to requests from any other site, which is the precondition for cross-site request forgery against session refresh. Strict has its own failure: the cookie is not sent back after a cross-site redirect, so a federated sign-in that returns through an external identity provider loses the session.
How it relates to other screens
Federated sign-in, machine identities and passkey attestation are configured from the three other entries in this same group, not from the rows above:
Who the accounts are, what they may do, and the tokens they hold are administered elsewhere:
The keys the rotation period governs, and the actions that rotate or revoke one at once: