Account dashboard
Every user has a self-service area at https://auth.infra.delta.rocks/account. It shows what the server knows about you, which apps you gave access to, and lets you manage organizations, clients and audiences you own.
Signing in
Opening /account starts a normal sign-in with the built-in "Account" app. The sign-in screen offers:
-
a username field (browsers may suggest saved passkeys right in it), or
-
"Sign in with a passkey" without typing a username.
After entering a username you get "Sign in with a passkey" and, if you have a password, "Use password instead".
First sign-in
There is no self sign-up. An administrator creates your account and gives you a username and a one-time secret code (see Admin access). On the first sign-in, enter the username, then the "Secret code" and a new password. Add a passkey afterwards.
Passkeys
Use "Add passkey" in the dashboard header (it opens /add-passkey) and click "Create passkey". If the
authenticator supports it, the passkey can also unlock your end-to-end encryption keys: you are asked to use it
once more ("Enable encryption keys"), or you can choose "Skip, use it for sign-in only". The Sign-in methods
page then tells you what happened, for example "Passkey added. Sign in with it and confirm once with another
method to let it unlock encryption keys", or "This authenticator can't unlock encryption keys".
Why security keys need a PIN
pykrete requires user verification for every passkey: a fingerprint, face, device unlock or, on a hardware security key, a PIN. A key that only checks "user present" (a touch) is rejected with "authenticator did not verify the user, security keys need a PIN set".
This is deliberate. A passkey replaces your password and can unlock your encryption keys through the WebAuthn PRF extension. Authenticators compute a different PRF secret with and without user verification, so allowing both would break the encrypted key envelopes, and touch-only would make unlocking your keys possession-only.
fido2-token -S <device> from libfido2, then
add the passkey again.Layout
The header shows your picture (or initial), name, @username and member-since date, and the buttons "Add
passkey" and "Sign out". Admins also see "Enter admin mode" there (see [admin-mode]). The sidebar groups the
pages; numbers next to entries are counts (for example active access tokens).
| Group | Page | Path |
|---|---|---|
Account |
Profile |
|
Emails |
|
|
Sign-in methods |
|
|
Sessions |
|
|
Pending sign-ins |
|
|
Organizations |
|
|
Access |
Applications |
|
Access tokens |
|
|
App passwords |
|
|
API keys |
|
|
E2EE |
|
|
Roles |
|
|
OIDC |
Clients |
|
Audiences |
|
|
App key scopes |
|
Account pages
Profile
Shows your user ID (with a copy button; apps and admins use it to refer to you), name, when the profile was last updated, member-since date, every username you had (current first) and your email addresses.
You can upload or remove your picture (at most 2 MiB). Name and username can't be changed from the dashboard yet.
Emails
Lists your addresses with a "verified" or "unverified" badge and, for unverified ones, whether a verification link is pending.
-
"Send verification link" adds an address and emails a link. The link opens
/account/emails/verify?code=..., where "Confirm email" verifies it. Links are valid for 24 hours and only work for the account that requested them. -
"Resend link" sends a new one, at most once a minute.
-
"Remove" deletes the address.
-
You can have at most five unverified addresses at a time, and an address verified by another account can't be verified again.
The server emails the link when email is configured (see Email). Without it, no email is sent and the link only appears in the server log.
Verified addresses matter for organization invitations sent by email: only an account with that verified address can accept them.
Sign-in methods
Lists your credentials: "Password", "Passkey" (with a short id), "Password setup code" (an unused registration code), "Authenticator app", "YubiKey OTP" and "YubiKey OTP (YubiCloud)" (both with the key's public ID). A badge marks credentials that can unlock your encryption keys, and a summary line shows the encryption key fingerprint and how many credentials wrap it.
Add passkeys with "Add passkey" in the header. Second factors can be removed with "Remove"; passwords and passkeys can't be removed from the dashboard yet.
Two-factor authentication
With a second factor set up, signing in with a password also asks for a code. Signing in with a passkey doesn't, because passkeys already require a PIN or biometric check. Once a code was accepted, the browser session doesn't ask again.
The code field takes any of:
-
the 6-digit code from an authenticator app,
-
a code typed by touching a YubiKey,
-
one of your recovery codes.
After five wrong codes the sign-in stops and has to be started again. Each code works only once.
"Add authenticator app" shows a QR code and the setup key. Scan it (or tap "open it in the app" on a phone), then enter the code the app shows to finish. The setup page works for 15 minutes.
"Add YubiKey" registers a Yubico OTP slot, in one of two ways depending on the server configuration.
When the server uses YubiCloud, touch the key once to type a code into the field. This works with the credential most YubiKeys ship with in slot 1. Every code is then checked with Yubico's YubiCloud service, so Yubico learns when the key is used here.
When the server has otp_secret, you can instead program a slot yourself and have codes checked by the server
alone. Program a slot with YubiKey Manager, paste the private ID and secret key it prints, then touch the key to
type a code into the last field:
ykman otp yubiotp --serial-public-id --generate-private-id --generate-key 2
Slot 2 is triggered by a long touch. Slot 1 usually holds Yubico's factory credential, which other sites may rely on.
Adding the first second factor creates ten recovery codes, shown once. Each works once in place of a code. "New recovery codes" replaces them all. Removing the last authenticator app or YubiKey also deletes the recovery codes. If you lose all of them, an administrator can remove your second factors (see Lost second factor).
Authenticator apps and self-programmed YubiKeys need otp_secret on the server, YubiCloud keys need yubicloud
(see Configuration). With neither, two-factor authentication isn't
offered.
Sessions
One entry per browser where you are signed in to pykrete, with the time it started and the sign-in methods passed in it (for example "Passkey"). Ending a single session from here is not available yet; "Sign out" ends the session of the current browser (see [sign-out]).
Pending sign-ins
At the top, requests from machines waiting for your approval (backchannel requests, see CIBA), marked "waiting for you". Each shows the app, its message (for example "nas1: unlock 2 disks"), the address the request came from, when it was made and expires, and the requested scopes.
-
"Review" opens the approval page. Sign in (with a passkey or password if the request includes encryption keys), check the message, address and time shown above the permissions, then "Allow" or "Deny". If you are signed in with another account, the page asks you to sign in as the account the request is for.
-
"Deny" rejects the request right away.
Approve only requests you expect. A request you didn't start can mean someone has a copy of the machine's credentials.
Below them, sign-ins that are not finished yet: authorization codes issued to an app that the app has not exchanged, and device sign-ins you approved that the device has not picked up. Read-only. Each entry shows when it was created and when it expires; expired entries are marked "expired".
Organizations
-
Invitations addressed to your account, with "Accept" and "Decline".
-
Your organizations with the permissions you have in each.
-
New organization: a slug (lowercase letters, digits and dashes), a name and an optional picture. You become its admin.
Everything inside an organization is described in Self-service.
Access pages
Applications
Every app you granted access to, grouped by what it can see: "Your identity" (built-in permissions such as profile and email) and one group per API (audience) with the scopes you approved.
Revoking a grant from here is not available yet.
Which of your organizations an app may see is chosen on the sign-in screen, when the app uses organizations: "Visible to this app" toggles them, "Continue as" picks the active one, and "Not enabled for this app" lets you request access for organizations that haven't enabled the app. There is no dashboard page for these decisions yet; see Organizations for when the screen appears again.
Access tokens
All access tokens issued to you, newest first; expired ones are folded away. Each entry shows the app, a short id, the grant type, issue and expiry time, scopes, audiences, the refresh token state and, under "Claims", the access and ID token claims. "this page" marks the token the dashboard itself is using. Tokens can't be revoked from here.
App passwords
Passwords for apps that sign you in over LDAP, with the app and creation date. Administrators issue and revoke them; creating your own is not available yet. See LDAP.
API keys
API keys that apps created for you through the Backend API: name, prefix, app, who created it, last use, expiry, scopes and state. "Revoke" disables a key immediately; revoked and expired keys stay listed under a fold. New keys are only created by the apps that use them, see Backend API.
E2EE
App encryption keys: one per key name, created the first time an app is issued an app_key:... scope for you.
Shows name, description and creation date. Read-only. See App encryption keys.
Roles
Global roles an administrator granted you, with their id and description. Roles you hold inside an organization are shown on that organization's Members page.
OIDC pages
"Clients", "Audiences" and "App key scopes" are for developers: register your own OIDC clients (apps), APIs and end-to-end encryption key scopes, personally or for an organization. See Self-service and App encryption keys.
Admin mode
Users with an admin role see "Enter admin mode" in the header. It asks you to sign in again and then shows an "Admin mode" badge and "Exit admin mode". Details in Admin access.
Signing out
"Sign out" in the header always removes the dashboard's own token. If the browser is signed in to pykrete, it then asks:
| Choice | Result |
|---|---|
Stay signed in |
Only the dashboard is signed out. Your pykrete session stays, so the next visit to |
Sign out of pykrete |
Ends the pykrete session in this browser. The next sign-in anywhere asks for a passkey or password again. |
Either way you end up on the server's start page. Apps you are signed in to keep their own sessions and tokens; sign out in each of them. When you end your pykrete session from an app's sign-out, the dashboard's token is removed too.