- GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET must be set in environment variables if you want Google sign-in.
- MICROSOFT_CLIENT_ID and MICROSOFT_CLIENT_SECRET must be set in environment variables if you want Microsoft sign-in.
- PAYLOAD_SECRET must be set in environment variables, or the sign-in handshake cannot be completed.
- For Microsoft sign-in, your Azure app registration must request the xms_edov optional claim, or accounts from organisational directories will be refused.
Step by step
- Find the sign-in button on the admin screen
Open the Daviah admin sign-in screen. If Google or Microsoft credentials are configured on your platform, you will see a 'Continue with Google' or 'Continue with Microsoft' button. If neither button appears, the credentials have not been set up. A note below the buttons reads 'By continuing you accept the Terms of Service.'
- Use the same buttons from the public pages
The same Google and Microsoft buttons appear on the public-facing join and portal pages, not just the admin screen. They work identically and post to the same route. If no credentials are configured, no buttons appear on those pages either.
- Press the button to start the sign-in
Pressing the button submits a form to Daviah's server. Daviah checks that the request came from its own hostname, applies a per-IP rate limit, and then generates a unique handshake containing three random secrets and a record of the current terms version.
- Pick your account at Google or Microsoft
Google or Microsoft shows you their own account-picker. You are always asked to choose an account — Daviah sends the prompt=select_account instruction every time. Select the account you want to use and approve the request. The provider then sends your browser back to Daviah.
- Daviah receives the callback from the provider
Daviah reads the handshake cookie that was set in step 3. It applies two rate-limit checks. It then begins verifying the response. Whether sign-in succeeds or fails, the handshake cookie is deleted immediately so it cannot be used a second time.
- Daviah runs six security checks in order
Daviah confirms: credentials are still present; the handshake cookie exists and has not expired; the state value returned by the provider matches the one sent, preventing cross-site request forgery; the provider did not return an error; the authorisation code is exchanged for tokens using the full PKCE secret; and the returned identity token is verified against the provider's published keys, checking the signature, expiry, audience, issuer, and nonce. Your name and email are then read from the verified token.
- Daviah finds or creates your user record
Daviah looks for an existing account linked to your provider identity. If one is found and the account is active, you are signed in straight away. If your identity is new, Daviah checks that your email address was confirmed by the provider — unconfirmed addresses are refused. It then searches for an existing account with your email address and links the new identity to it, or creates a brand-new account if none is found.
- Your session is created
Daviah loads your user record, confirms your account is active, and mints a session cookie using exactly the same method as a password sign-in. Your last-signed-in time is updated. The session cookie is sent back to your browser.
- Your browser is sent to the admin area
Daviah redirects your browser to the admin area. If your account was just created, Daviah records the new sign-up for analytics.
- New accounts: tell Daviah what you run
If your account is brand new and has no organisation attached, the admin area sends you to the 'What do you run?' screen. Submitting the form sets up your first organisation and takes you into the admin area.
What happens next
You are now signed in to the Daviah admin area with a full session, the same as if you had used a password. If your email address was already in the system — for example because an administrator added you manually — your existing account is used and your Google or Microsoft identity is attached to it for future sign-ins. If you were completely new to the platform, a user record was created for you and you were taken through the 'What do you run?' screen to create your first organisation.
Good to know
Microsoft sign-in distinguishes between personal accounts and organisational directory accounts. Organisational accounts are only accepted if your Azure app registration includes the xms_edov optional claim. Without it, Daviah cannot confirm the email address is verified and will refuse the sign-in. If your team uses Microsoft 365 or an organisation-managed Azure directory, make sure this claim is requested before asking people to sign in.
The handshake cookie that protects the sign-in flow is deleted the moment the callback is received, whether or not sign-in succeeded. This means a link or response from the provider can only be used once. If someone lands on an error page, they simply start again by pressing the button.
Daviah — Let your team sign in to Daviah using their existing Google or Microsoft account instead of a separate password.