All token comparisons (invite tokens, verification tokens, password reset tokens, OAuth state) use constant-time string comparison. This prevents an attacker from inferring valid token prefixes by measuring response latency.

Standard string equality (String.equals) short-circuits on the first mismatch and leaks timing information. restheart-accounts uses MessageDigest.isEqual on the SHA-256 digests of both values — a standard constant-time technique.

All tokens (invite, verification, password reset, OAuth state) are:

Password strength is enforced server-side using the zxcvbn algorithm (Dropbox) at the point of:

The minimum score is configurable (minimumPasswordStrength, default 3 = "Strong"). Client-side zxcvbn checks are encouraged as UX guidance but are not trusted as security controls.

Before issuing a JWT on invitation activation, the server clears any existing session. This prevents a logged-in user from accidentally activating an invitation as a different identity (session fixation variant).

Consent tracking (terms & conditions, privacy policy versions) is not handled by the Accounts plugin. See Consents Management for guidance on implementing custom consent tracking. === Google OAuth security

When accountsInitializer is enabled, it unconditionally restricts what the generic MongoDB REST resource at /users can be used for, regardless of any ACL the application defines:

Why: an ACL commonly grants an authenticated user permission to PATCH their own /users/{email} document, so they can self-edit their profile (name, avatar, …​). Without this restriction, that same permission would let the user rewrite any field on their own document — including roles, team/teams, or a directly-set password — which is a privilege-escalation path (e.g. promoting themselves to owner in a team, or joining a team they were never invited to). This restriction closes that path unconditionally, for every application built on restheart-accounts, independent of how permissive its own ACL is.

This does not affect any restheart-accounts endpoint itself: every service that legitimately needs to set roles, team/teams, tokens, or a hashed password writes to MongoDB directly via the driver, not through the REST resource — so none of those flows are subject to this restriction.

If your application has its own reason to let certain accounts write more than profile.* to /users via the generic REST resource (for example, an internal admin console that manages roles/teams directly), configure users-unrestricted-roles in accountsConfig:

Accounts with any of the listed roles bypass this restriction entirely — both the PUT/POST block and the profile.* limit on PATCH. Leave it unset (the default) to apply the restriction to every caller, with no exceptions.

In a multi-tenant deployment, users-unrestricted-roles can also be overridden per team via override-accounts-users-unrestricted-roles — see Multi-tenancy for the full override mechanism.

accountsInitializer is enabled at the node level, independent of whether a given tenant has actually opted into restheart-accounts (e.g. RESTHeart Cloud enables it once per service node, but Sign-up Management is an opt-in feature per service). A tenant that never enabled it never opted into these opinions on /users either — so a deployment-layer interceptor running before authentication (e.g. TeamConfigInterceptor, at REQUEST_BEFORE_EXCHANGE_INIT) can attach override-accounts-signup-mgmt-enabled: false to skip the restriction entirely for that tenant, for every caller. This must be set before authentication: the veto is evaluated as part of authorization, which runs before any REQUEST_AFTER_AUTH interceptor gets a chance to run.

Which user-document fields are copied into an issued JWT, the claims that always survive a per-tenant override, and the denylist that no configuration can bypass, are described in Authentication — JWT claims.

They are documented there rather than here because they are not specific to restheart-accounts: the same JwtIssuer applies them to every token this deployment issues — on /token, from the accounts endpoints, and to OAuth authorization codes alike.

restheart-accounts relies on RESTHeart’s built-in bruteForceAttackGuard (sliding-window rate limiter per IP) for protection against token-guessing and credential stuffing.