Signing in

Who this page is for: anyone signing in to Refera, and the practice owner deciding how staff access changes when the workspace goes live.

The short version

• Passkey: the recommended live sign-in. It is phishing-resistant and uses Face ID, Touch ID, Windows Hello, a device PIN or a hardware security key.
• Authenticator alternative: where passkeys are unavailable, confirm a single-use email link and then enter the current 6-digit code from the enrolled authenticator app.
• Recovery code: a one-time route into restricted factor replacement. Recovery proof never opens referral data.
• Unattended browser: every human session locks after one hour without activity, even though the absolute session ceiling is 12 hours.

Refera has no passwords.

Recover access

Start at portal.refera.au and enter your own work email.

1. Try your passkey again if your device still has it.
2. Otherwise, choose Email a secure link. For a live workspace, Refera will also ask for the current code from your enrolled authenticator.
3. If you have lost that authenticator, use one saved recovery code after confirming the email link. This opens factor replacement only; it does not open referral records.
4. If none of those routes is available, contact Refera support.

Use your individual work account, not the shared referral mailbox. Refera support cannot display a passkey, authenticator secret or recovery code, and cannot bypass the practice’s access controls.

One account per person

Every receptionist, practice manager and owner signs in with their own account and unique work email. Do not share a sign-in or add [email protected] as a staff account. That shared mailbox is an intake source only.

Separate accounts let the practice remove one person’s access without disrupting the rest of the team, and keep each sealed workflow action attributed to the person who performed it. The worklists remain practice-wide. See Team accounts and roles.

An Owner or Admin can send a generic invitation from Settings > People > Members and roles. It contains the practice workspace name, role and sign-in page, with no patient or referral information. The invitation does not weaken sign-in: each person still uses their own passkey or the email-plus-authenticator route for a live workspace.

Account creation verifies the mailbox first

Account-first setup sends a single-use verification link that lasts 30 minutes. Merely opening that link does not consume it, so an email security scanner cannot accidentally finish signup. The signer must press the confirmation command on the page. Only then does Refera create the empty workspace, seal the accepted terms and generate the agreement PDF. If the initial mailbox-verification email cannot be confirmed as sent, no workspace is created. After the signer has explicitly confirmed that proof, the sealed workspace is durable: a later sign-in-link or receipt delivery failure is reported as a retryable delivery problem and never pretends that the workspace or accepted agreement disappeared.

Email links prove the work mailbox

A user can request a single-use email link to prove control of the work mailbox. During account setup, that proof can resume the capture-off workspace. For a live workspace it is only the first half of the authenticator route: a current TOTP code is still required. The sign-in confirmation is bound to a short-lived, host-only cookie so a different site cannot silently swap the signed-in account. GET, HEAD and link-preview requests do not consume the token.

Rule	Enforced value
Lifetime	15 minutes
Uses	Exactly one
Active links	One per email; requesting another cancels the old link
Requests	Rate-limited per email and network address
Storage	SHA-256 token hash only; the raw link exists once, in the email
Enumeration	Known and unknown addresses receive the same response

Use the sign-in page to request this link. New practices start with account setup.

Passkeys are preferred, not mandatory

Activation automatically changes the API access decision. A live referral workspace accepts either a user-verified WebAuthn session, or a session that contains both verified email proof and a current TOTP authenticator code. Email alone, TOTP alone and recovery proof are refused.

A passkey remains the recommended route because it is phishing-resistant and does not depend on waiting for email. The authenticator route exists for staff whose browser, device or local policy cannot use a passkey.

Staff can select Sign in with a passkey at the licensed portal. Passkey challenge responses for known and unknown emails remain indistinguishable, so the route does not reveal which people have Refera accounts.

Session controls

• The absolute session ceiling is 12 hours.
• One hour without activity locks the session. The server updates activity at bounded intervals rather than on every request.
• Production uses a __Host-refera_session cookie with Secure, HttpOnly, SameSite=Strict, Path=/ and no Domain attribute. Page scripts cannot read it.
• API clients can use the matching bearer. Server-side session records store only hashes.
• Sign-out revokes the current session immediately.

Factor lifecycle

Mailbox proof lets the first passkey or authenticator be registered. Once a factor exists, sensitive factor operations require fresh strong proof. Adding, replacing or removing a factor rotates the relevant authentication state and revokes older sessions so a copied session cannot outlive the security change.

Refera emails a generic security notice after a passkey or authenticator is added or removed, a recovery code is used, or recovery codes are replaced. The notice contains the practice, activity and time only. It never includes a factor secret, passkey, recovery code, referral or patient detail. A mail-delivery problem is recorded for operations but cannot roll back or bypass the completed security change.

Removing a factor cannot leave a live account without a viable live-access method. Add and verify its replacement first, then remove the old method and sign in again.

Recovery codes replace a lost factor

Refera issues ten one-time recovery codes. Save them outside the device used to sign in. Each code is shown only when issued, works once after email confirmation, and opens only the factor replacement ceremony. It cannot read or export referrals. Creating a fresh set immediately invalidates every old code and requires recent passkey or email-plus-authenticator proof.

Refera retains verification values for recovery codes, not the original codes, so support cannot display them later. This property applies to recovery codes, not referral records.

What ships now

Surface	Production posture
Mailbox proof and workspace resume	Single-use email confirmation with enumeration silence
Live workspace	User-verified passkey, or verified email plus current TOTP
WebAuthn origin	Bound to portal.refera.au
TOTP	Live only when combined with the single-use email proof for that session
Recovery	Restricted factor replacement only; never referral access
Session lock	12-hour absolute ceiling plus a one-hour idle lock
Production cookie	Host-only __Host-refera_session, Secure, HttpOnly and SameSite Strict
Factor changes	Recent strong proof, session rotation, and viable-method floor
Security alerts	Generic transactional email after factor and recovery changes; no clinical content

These properties are asserted on every release: mailbox proof, email-link single use and expiry, enumeration silence, passkey registration and sign-in, email-plus-TOTP access, recovery isolation, idle expiry, host-only cookie flags and session revocation. The gate also checks scanner-safe GET/HEAD behaviour, same-origin confirmation, recovery-only refusal across protected API routes and the fixed security-alert content.

The wall that does not move

Signing in decides who is at the desk. It never changes queue order or interprets referral content.

Refera tracks referral admin only. It does not triage patients.