List all configured users in NanoIDP

Get details of a specific user

Create a new user in NanoIDP

Create a password-less user for persona login mode (local dev/testing convenience, 'login.mode: persona' in settings). The user can only authenticate by identity selection in the interactive login UI - never via password-mode login or the OAuth password grant. To keep 'create_user' unambiguous (always creates a normal, password-protected user), this is a separate tool rather than an optional password on create_user.

Delete a user from NanoIDP

Update an existing user's attributes

Generate an OAuth2 access token for a user

Decode and display the claims in a JWT token (without signature verification)

Verify a JWT token's signature and expiration

List all configured OAuth clients

Get details of a specific OAuth client

Create a new OAuth client

Update an existing OAuth client

Delete an OAuth client

Get current NanoIDP settings

Reload configuration from files

Validate the running configuration directory (settings.yaml, users.yaml, bootstrap.yaml): unknown keys as warnings, wrong types and refused values as errors. settings.yaml and users.yaml findings are what a startup or the next reload would hit; bootstrap.yaml findings are what would stop the NEXT startup (the bootstrap surface loads at startup only). Read-only and inert: it re-reads the files through the same loaders, runs no hook and loads no plugin. 'valid' is false on any error, and on a warning too under strict mode, which is when a start would refuse. 'strict' defaults to this server's effective validation mode; pass it explicitly to override.

Update NanoIDP settings (issuer, audience, token expiry, SAML options, etc.). hooks: and plugins: (#185) are YAML-only, like secret_key and require_ui_login: they are reported by get_settings but cannot be changed here, since a command editable through the surface it observes would be a remote-execution primitive.

Save current configuration to YAML files (persists changes made via create/update tools without persist=True support). Writes users.yaml and settings.yaml as one coordinated, conflict-checked save (#229) and then refreshes the running configuration from what was just written. To refuse the save if another writer (the web UI, another agent, a second nanoidp process on the same directory) changed a file since you read it, pass the expected_users_revision / expected_settings_revision a read tool handed back (list_users and get_user carry users_revision; list_clients, get_client and get_settings carry settings_revision; reload_config and a successful save_config carry both). save_config always writes both files, so there are exactly two modes: omitting both revisions keeps today's unconditional last-write-wins, and supplying either makes the WHOLE save conflict-checked - the omitted revision defaults to the one this runtime was loaded from, so a save guarded on users.yaml cannot silently overwrite a settings.yaml another writer changed, or vice versa. A failure response's 'kind' distinguishes four outcomes: 'conflict' (nothing was written - a supplied revision was stale; call reload_config, reapply your change on the fresh state and save with the revisions from its response), 'lock_timeout' or 'lock_unsupported' (nothing was written either - the write never started; lock_timeout is worth retrying, lock_unsupported means this config directory's filesystem does not support advisory locks and will not succeed on retry), a hook's own 'kind' under hooks.strict (both files ARE written; only the mirror push failed), or 'reload_after_save' (both files ARE written but the runtime could not adopt them - do not retry expecting a different result, the file on disk is authoritative).

Get OIDC discovery document (/.well-known/openid-configuration)

Get JSON Web Key Set for token verification

Get audit log entries (what the IdP recorded: token requests, logins, SAML flows)

Get audit log statistics (event counts by type/status)

Clear the audit log

Get information about the signing keys (active kid, previous keys)

Rotate the signing keys: the active key moves to 'previous' (still valid for verification) and a new active key is generated - useful to test clients' JWKS refresh handling