Security, 2FA and OIDC

nia-todo supports password authentication, TOTP, passkeys/WebAuthn, recovery codes and OIDC. Security-sensitive actions require fresh reauthentication when MFA is active.

HTTPS and public URL first

Before enabling passkeys or OIDC:

1. Publish the instance through HTTPS.
2. Save the exact public base URL in /admin.
3. Confirm that the native app, browser and reverse proxy all use the same origin.

Passkeys are bound to this origin and relying-party ID. Non-localhost production passkeys fail closed without a configured public URL.

User 2FA

Users manage their factors in the app settings:

• authenticator-app TOTP
• passkeys
• single-use recovery codes
• active and trusted device sessions

Recovery codes are shown when generated and should be stored outside nia-todo. Removing the last primary factor also removes recovery-code access.

The administrator can require 2FA globally. Enable that policy only after confirming that users can enroll and that your account-recovery process is understood.

OIDC single sign-on

nia-todo supports a generic OpenID Connect provider using discovery. Register this redirect URI at the provider:

https://todo.example.com/api/oidc/callback

Then configure in /admin:

• provider display name
• HTTPS issuer URL
• client ID
• client secret, unless explicitly using a public client
• token authentication method (usually auto)
• scopes (default: openid email profile)

OIDC users are matched strictly using a verified email address on both sides. The administrator’s OIDC identity must be linked manually from an authenticated admin session.

API keys

Users can create scoped machine credentials from settings. API keys use the ApiKey nt_... authorization scheme and are intentionally separate from browser MFA challenges. Creating or revoking keys requires fresh MFA reauthentication when MFA is required.

Treat API keys like passwords: store them in a secret manager, do not embed them in public scripts and revoke unused keys.