Sign-in methods
How people prove it is them. Nothing to configure on your side.
The user picks the method on our screen. Your site does not know which one, and should not: it gets the same result whether they typed an emailed code or touched a fingerprint sensor.
Emailed code
The default. A six-digit code, valid for 10 minutes, five attempts.
There are no passwords anywhere — not at registration, not later. There is no separate registration step either: the first verified address creates the account.
Passkey
Sign-in by fingerprint, face or device PIN, over WebAuthn. The key is bound to the auth.my domain, so one key works across every connected site.
It resists phishing by construction: a key issued for auth.my will not fire on a look-alike site, however convincing the copy.
Google and Microsoft Entra
A button on the sign-in screen. If the address from the social provider already exists here, the accounts link automatically — but only when the provider states that the address is verified.
Microsoft never sends a verified-address flag. So on the first Entra sign-in we email a code and ask for it. Without that, someone else's Entra account carrying your address would be a takeover of your account here.
Backup codes
One-time codes for when neither email nor device is reachable. Issued as a list, each works once, and reissuing invalidates the previous set.
We store only hashes — the code itself cannot be recovered, only replaced.
What your site sees
The id_token carries amr — how they signed in:
| Value | Method |
|---|---|
otp | emailed code |
passkey | passkey |
backup_code | backup code |
social | Google or Entra |
social, otp | first Entra sign-in with address confirmation |
Alongside it comes auth_time — when the person actually entered a code or
touched the sensor. Useful if you have operations that need fresh
authentication: compare auth_time with now and, if needed, send the user
back with prompt=login.
Your site cannot demand a specific method at sign-in: that choice belongs to the user and to us.