Sessions, passwords and passkey models in your tenant

Idle timeout

A browser that signs in to your tenant's pages gets a session that lasts for the Signed-in session lifetime in Flow Policy. Sign out after this long unused adds an idle timeout: a session that is not used for that long ends, whatever its lifetime. It is off (0) by default. Otherwise it is at least 300 seconds and no longer than the lifetime. A page view, a sign-in step or an authorization request counts as use, noted at most once a minute.

When a session ends this way, the next request from that browser finds it gone and is asked to sign in, and protocol Audit records account.sign_out with the reason session_idle_timeout. An authorization request from an idle browser asks the person to sign in instead of returning a code. Tokens already issued to applications are not affected.

Where people are signed in

Each person's Security page at /account/security lists the browsers signed in to their account: the browser and operating system, when it signed in, when it was last used and how. The browser and system are classified names, such as Chrome on Windows; the browser's own description is never stored. Sign out ends one other session and Sign out of all other browsers ends every session except the one in use. Use Sign out on the Profile page for the browser in use.

Administrators open View/edit details (View details without permission to edit the user) on a user's row in User Management. The same list appears there, with where each session is: on this tenant's pages, or on the Beyond the Login site for a BTL user whose home org this is. Sign out ends one session. Sign out of every browser ends all of them, forgets trusted browsers and cancels sign-in steps still waiting, after a confirmation.

Ending a session signs a browser out. It does not revoke tokens an application already holds, because a refresh token can outlive the session that approved it. To end those too, disconnect the application in the same details view, or lock the user. Each session is named by a public session ID; the session secret and its hash never leave the tenant store. A BTL user's sessions are listed for the org's administrators, but only the person, from their own Security page, or BTL support can end them. BTL support sees and ends them from the account's details in BTL Admin, and this tenant's Audit records each read and sign-out as BTL support.

Password rules

The Password settings on the Authentication page set the rules for every new password, wherever it is set: registration, reset, the Security page, an administrator setting one, and SCIM.

• Minimum length, from 8 to 64 characters. The maximum is always 128.
• Kinds of character required, from none to all four: uppercase letters, lowercase letters, numbers and symbols. Length matters more than the mix, and many current guidelines ask for no mix at all.
• Earlier passwords that cannot be reused, from 0 to 5. A new password can never be the current one. To check earlier ones, their hashes are kept for each user, only as many as this rule asks. Lowering the number removes the extra hashes, and 0 removes them all.
• Refuse passwords found in known data breaches, on by default. Only a short prefix of a hash of the password is sent to a public breached-password range lookup. Turning it off lets people choose passwords attackers already know, so the page warns while it is off. Keep it on outside a contained lab.

A new tenant starts with at least 8 characters, no required kinds of character and the breached-password check on. Your tenant can choose its own rules within the ranges above. New rules apply when a password is set or changed, so passwords set under earlier rules keep working. A tenant that saved its password settings before these defaults keeps the rules it saved.

Pages show the tenant's rules next to each new password field. A password that breaks them is refused with the reason password_rules_unmet, and a repeated one with password_reused, in protocol Audit or, when an administrator sets it, in the User directory Audit.

Password age

Ask for a new password after sets a maximum age from 30 to 365 days, or 0 for none, the default. After a password sign-in with a password older than that, the person chooses a new one before continuing, on the same page that asks for required methods. Signing in another way, such as with a passkey, does not ask. Forced periodic changes tend to produce predictable passwords, so use this only when a rule you follow requires it. The age counts from when each password was set. Passwords set before this setting existed count from the last change to the user's record.

Wrong passwords

Wrong passwords on the Authentication page decides what repeated wrong passwords do, on the tenant's sign-in page, at the authorization endpoint and for the current password the Security page asks for before a change, alike. Only wrong passwords count. Other sign-in methods, such as email links and passkeys, are never blocked by it, and an address with no account locks the same way, so the answer never shows which accounts exist.

• Slow down guessing on that network, the default. After the chosen number of wrong passwords from one network within the chosen minutes, that address is refused from that network until the time is up. The right password keeps working from any other network. Once an address fails 20 times from anywhere within 15 minutes, every network is slowed to one try a minute. Knowing someone's address is never enough to lock them out.
• Lock password sign-in for the address. After the chosen number of wrong passwords from any network within the chosen minutes, password sign-in for the address is locked everywhere for that many minutes, counted from the wrong password that started it. This is the lockout many directories and banks use. Anyone who knows an address can start it, so the page warns when locked-out people would have no way back in except waiting.

Choose from 3 to 20 wrong passwords and from 5 to 1,440 minutes. The defaults are 5 and 15. The address-wide slowdown in the first mode is fixed, because it protects every tenant's sign-in pages from distributed guessing.

With locking, Email a link that unlocks the account sends the account's address a link when a lock starts, with a warning to reset the password if the attempts were not theirs. Opening the link shows a button, so mail scanners that follow links cannot use it. The link works once, lasts as long as the lock and lifts only the lock: it neither signs anyone in nor changes the password. It shares the address's sign-in email allowance. Whether or not it is on, a completed password reset ends a lock, and an administrator who holds tenant.users.unlock can choose Unlock password sign-in on the user's row in User Management, where the status shows until when the address is locked.

Protocol Audit records account.lockout with the reason locked_out when a lock starts, naming the user as subject when the address belongs to one and never as the actor. account.unlock records the email (unlock_link_sent, or why it was not sent) its use (sign_in_unlocked), and a used, replaced or expired link presented again (link_used, link_expired), with the user as subject and never as the actor. A sign-in the lock or slowdown refuses is recorded as account.sign_in rejected rate_limited with the limit that refused it, at most once a minute per account, limit and network; Logs count every one. An administrator's unlock is recorded in the User directory Audit as tenant.users.sign_in_lockout.clear, which says whether a lock was in place. The tenant's Usage view shows how many addresses each mode is holding back, against the tenant's own numbers.

Passkey attestation and models

Attestation decides what the browser is asked for when someone adds a passkey: None, the default, Indirect, where the browser may anonymize the statement, or Direct, the authenticator's own signed statement of its model, its AAGUID. Many browsers and synced passkeys send no statement whatever is asked.

Allowed authenticator models limits new passkeys to the AAGUIDs you list, up to 50, and needs Direct attestation. A passkey of another model, or one that sends no statement, is refused, and protocol Audit records passkey_not_allowed with the model it reported. The statement's signature is always checked. On its own, that shows only the model the authenticator states, since anyone can make a key that claims a listed AAGUID. Passkeys added before the list keep working. The model and attestation format of each new passkey are stored with it.

Verify models with the FIDO Metadata Service closes that gap, and also needs Direct attestation. Beyond the Login fetches the FIDO Alliance's signed metadata file once a day and verifies its signature before using it. With the check on, a new passkey is accepted only when its attestation certificate chains to one of the root certificates its model registered there, and the model has not been reported as compromised or revoked. A passkey that sends no attestation, which includes most synced passkeys, a model the service does not list, and a certificate from any other issuer are refused, and protocol Audit records attestation_not_anchored, model_not_certified or model_compromised with the model reported. If no verified copy from the last two weeks is available, new passkeys are refused with metadata_unavailable rather than accepted unchecked, and the person is asked to try again later. The check can be used with or without an allowed list; with both, a passkey must pass both. Passkeys added before the check keep working.

Permissions, Audit and restores

Reading a user's sessions needs tenant.sessions.read and ending them needs tenant.sessions.revoke. Tenant Admin holds both, and custom roles can include either. Each read and sign-out is recorded in the User directory Audit with the user as subject and the first eight characters of the session ID. Idle timeout changes are recorded as Flow Policy changes, and password and passkey settings as Authentication changes, by setting name. A restore to an earlier time keeps an idle timeout, password rules and an allowed model list that were tightened after that time.

BTL accounts

BTL administrators set the same password and passkey settings for BTL accounts on the BTL organization's Authentication page. BTL accounts always keep the breached-password check and at least 8 characters; stricter rules are allowed. A BTL user manages their password, authenticator app, passkeys and recovery codes on Beyond the Login only. On their home org's own address, the Security page links to their Beyond the Login Security page instead of offering those changes, the password reset page points to Beyond the Login and sends no link of its own, and that org's password migrations never remove the password. They also always slow wrong passwords per network rather than locking an address, since an address-wide lock would let anyone who knows a BTL user's address keep them out of every tenant they manage. Each BTL account's Security page lists where it is signed in on the site, with the same sign-out actions. BTL administrators choose how long BTL accounts stay signed in on the site with BTL site session in the BTL organization's Flow Policy: 7 days by default, from 15 minutes up to 30 days, a longer range than tenant pages allow because people return to the site to learn over several days. That page's Sign out after this long unused setting applies on the site too, off by default. Accounts that hold a platform permission are always signed out after an hour unused and twelve hours after signing in, whichever comes first, however long the settings allow. A wrong current password on the Security page counts toward the same wrong-password limits as a sign-in.