Security & Sessions
Manage how you sign in and which devices have access from Account → Security & Credentials and Account → Active Sessions.
Password
Change your password at any time from the Security view. You’ll be asked for your current password; on success, all other sessions remain valid unless you revoke them (see Sessions).
Multi-Factor Authentication (MFA)
MFA adds a second step at sign-in. It is server-enforced — once enabled, the login response withholds the token until the second factor is verified, so it can’t be skipped by the client. Two methods are available:
| Method | How it works |
|---|---|
| Email OTP | A one-time 6-digit code is emailed to you at each sign-in. Recommended default. |
| Authenticator app (TOTP) | Scan a QR code into an app (e.g. 1Password, Google Authenticator) and enter the rotating 6-digit code. |
Enable MFA
Toggle Two-Factor Authentication on. Email OTP activates immediately.
(Optional) Add an authenticator
Click Add under Registered Authenticators, scan the QR (or enter the key manually), then confirm with a generated code. You can register more than one and give each an alias.
Choose your preferred method
If you have both, pick which one is used by default.
Passkeys (biometric / FIDO2)
Passkeys let you sign in with Touch ID, Face ID, Windows Hello, or a security key — no password. They use the WebAuthn standard and the private key never leaves your device.
- Register one from Security → Biometric Credentials & Passkeys → Register New Passkey, optionally giving it a device alias.
- Sign in later with Sign in with Passkey on the login screen.
- Revoke a passkey any time from the same view.
Passkeys and MFA are complementary: a passkey is a strong primary factor, while MFA protects password-based sign-ins.
Active sessions
The Active Sessions view lists every session for your account:
| Column | Meaning |
|---|---|
| Device | Parsed from the user agent (e.g. Chrome / macOS, or Nanokit CLI). |
| IP Address | The source IP of the session. |
| Location | Derived from the request country (via the edge CF-IPCountry header). |
| Last Activity | Relative time of the last request (your current session is highlighted as Active now). |
You can revoke any session except the current one. Revoking immediately invalidates that session’s token (session-backed revocation). Revocation events are surfaced as toasts and recorded in the Notification Center.
Use Revoke all other sessions to sign out of every device except the one you’re using right now, in a single click — handy after losing a device or seeing an unfamiliar session.
Sessions expire automatically: a session whose token has been inactive beyond its lifetime (24h) no longer appears as active and is pruned, so the list stays bounded and never accumulates stale entries.
Single sign-on across Nanokit apps
The Nanokit web apps you use as a regular user — the Hub, Account, and the sign-in pages — share one session. Signing in once authenticates all of them, and signing out of any one signs you out of all of them.
How it works. A successful login establishes a session cookie scoped to your
account’s domain (e.g. everything under your-team.nkapp.at). Every user app
reads that shared cookie as the source of truth: open the Hub and you’re already
signed in to Account, and vice-versa — no second login. The gateway also sets a
hardened, JavaScript-inaccessible (HttpOnly) session cookie that authenticates
your API requests.
Single logout. When you sign out of one app, the shared session cookie is cleared and the server-side session is revoked. Any other Nanokit tab you have open detects this within a few seconds (or instantly when you switch back to it) and signs out too — so leaving the Hub open on one tab and logging out of Account on another will not leave the Hub connected.
The Admin panel is separate. The staff/operator Admin console keeps its own session and is not part of this shared sign-on: signing in to your user account never grants Admin access (that requires a staff‑admin role), and signing out of the user apps does not affect an Admin session, or vice‑versa.
Local development note. On the local
*.localhost/*.localdev domains, browsers handle cross-subdomain cookies inconsistently, so the session is additionally carried in the post-login redirect to keep local sign-in reliable across browsers. The shared-cookie single sign-on / single logout behaviour above is the contract for real (https) deployments.