People sign in to AWRA with a password, with a one-time link and code emailed to them, or with a work account they already have. Whichever route they take, they arrive at the same ordered set of checks — so a faster way in is never a weaker one, and adding a sign-in method can never quietly create a way around your MFA challenge.
The gate chain
The common way this goes wrong is not a broken lock — it is a second door built later, by someone in a hurry, that skips a check the first door performed. So in AWRA the sign-in methods do not each decide what to enforce. They authenticate, then hand over to one shared routine that runs every gate in a fixed order. A new sign-in route that forgets to call it does not work at all, which is a much better failure than one that works and skips MFA.
A deactivated person is refused by every method, and refused first — before anything has told them whether the credential they presented was correct. The attempt is written to the audit trail against their identity, so a wave of tries against a disabled account is visible rather than silent.
inactive_account — “Your account has been deactivated. Please contact support.”
An unverified address parks the person on the verification notice with a fresh link, rather than letting them in to do work that nobody can be contacted about. There is one exception, and it is a narrow one: when a provider hands us a verified address that exactly matches the account’s own, that is the same proof our verification email was trying to obtain, so it settles the address instead of demanding a round trip. A provider address that differs proves nothing about the account’s, and falls through to the normal flow.
If your organization requires everyone to sign in through a provider account, passwords are refused — and so are emailed links. That second half is the part worth reading twice. A link to somebody’s inbox is not your identity directory, and an organization mandating provider sign-in is mandating its directory as the authority on who its people are. Treating the inbox as an acceptable substitute would quietly reopen the door the policy exists to close.
sso_required — “Your organization requires signing in with your work account.”
Under an expiry policy, a password past its age sends its owner to set a new one. This gate is deliberately password-only: somebody signing in by link or by provider account is not presenting a password at all, so its age is not what is authenticating them. Bouncing them to a reset would block a sign-in the policy has no quarrel with.
password_expired — a reset link is sent automatically.
An administrator requiring a password change is an explicit instruction and outranks the sign-in method used. The related case is subtler: an account that has never had a password of its own — normal for someone invited who signs in by link or provider — blocks only the password route. Sending that person on a password-reset detour would be a bug, not a control.
The same billing check the dashboard and the route middleware use, applied at the door rather than one screen later. An expired free plan lands on the upgrade page instead of a half-loaded workspace.
This is the gate the whole design exists to protect. If an account has MFA enabled it is challenged — whether it arrived by password, by emailed link, or by a provider handshake. A fast sign-in method is not a second factor: the provider or the link replaces the password, and nothing more. The session is dropped back to unauthenticated while the challenge is pending, so a half-signed-in state cannot be used to reach anything.
mfa_challenge — recorded as an event, not a failure.
Every refusal above is an audit event with a reason code, not a generic failure. The trail separates inactive_account from sso_required from password_expired from a wrong credential, which is the difference between “someone is being stopped by policy” and “someone is guessing”. Those entries land in the tamper-evident audit trail, so the record of an attack survives contact with the attacker.
Signing in without a password
Ask AWRA for a sign-in link and the message contains a button and a six-digit code. The link is the fast path. The code is for the situation everyone has actually been in: the email arrived on your phone and you are trying to sign in on a shared warehouse terminal. Both are single-use, both expire together, and using either one immediately kills the other.
Mail security products and inbox previewers fetch the links inside messages before a human ever sees them. If arriving at the link consumed it, that automated fetch would burn the only credential the person had. So the page the link opens checks the token and shows a confirmation screen without spending it — the sign-in happens when the person confirms.
or enter this code
402917Expires in 15 minutes. Using one of these cancels the other.
A system that answers every dead credential with “expired” strands the one person who is not under attack: someone whose code stopped working because their link was opened on another device. So that specific case is named outright — and reaching it requires having genuinely spent the link, which means real access to the mailbox.
Everything else collapses into a single answer. A mistyped code, an expired code and an address with no account are deliberately indistinguishable, because the alternative turns the sign-in page into a tool for testing which of a company’s email addresses have accounts.
The link token carries 32 bytes of cryptographic randomness. Neither the token nor the code is stored in a readable form — only hashes — so the credential cannot be lifted from storage and replayed.
The pair expires fifteen minutes after it is minted, and the code accepts a small number of wrong attempts before it burns. Both figures are configurable per deployment.
Requesting a link always says the same thing: if that address belongs to an account, a link and code have been sent. Whether the address exists, whether the account is active, even whether the email failed to send — one answer, so nothing here enumerates your staff.
The credential remembers the address it was minted for. If the account’s email changes after the message goes out, neither half will sign in — closing the window where a link sent to a former address still works.
Automated submissions are detected and answered exactly as a human is, minus the email. A different response for bots is a signal to tune against.
The trail records the request and the redemption as distinct entries, and an incorrect code as a failure with its own reason. A link requested but never used looks different from one that was used.
Signing in with an account you already have
Provider sign-in matches a provider identity to an AWRA user by email address, which only works if the address has actually been verified by the provider. “Verified” is not one thing across five providers, though: some publish a claim saying so, one publishes nothing and guarantees it in the API instead, and one needs a directory-owned principal name to be convincing. Reading each provider on its own terms is the whole job.
A verified-email claim on the profile.
verified_email · email_verified
Microsoft
A claim, or a directory-owned principal name for work and school accounts.
email_verified · xms_edov
A verified-email claim on the profile.
email_verified
GitHub
No claim exists to read. The API only ever yields a primary, already-verified address — so a well-formed address here is the verified one.
guaranteed by the API, not a claim
Slack
A workspace-issued address, verified on the provider side.
provider-resolved address
A provider account whose address has no AWRA user is refused and told to ask an administrator for an invitation. This is worth being blunt about because it is often sold as frictionless onboarding: it is not onboarding at all. Nobody arrives in your workspace because they happen to hold a matching email address.
If a different Google or Microsoft account already points at an address, a new one claiming it is rejected rather than silently re-pointed. Quietly moving that link is the shape of an account takeover, so it is treated as one.
A user can link more than one provider and sign in with any of them. The only conflict is the same provider twice — that slot has to be freed from the profile page first.
A provider that declines to share an email address cannot be matched to a user, and the attempt is refused with that reason rather than guessing at an identity.
Provider sign-in works from the Android app through a short-lived browser-to-app handoff, scoped to the provider that started it so one provider’s callback cannot be redirected by another’s leftover marker.
A security policy can require provider sign-in for everyone in your organization, which is gate 3 above — refusing passwords and emailed links alike.
For the security questionnaire
Authentication is the section of a vendor assessment where marketing language collapses fastest, because the follow-up question is always specific. Here is what we would write in the box, phrased to survive being read by somebody whose job is to find the gap.
They askDo you support SAML 2.0 or OIDC federation with our identity provider?
No — not today, and we will not describe what we have as that. AWRA supports OAuth sign-in with Google, Microsoft, LinkedIn, GitHub and Slack accounts, which covers Entra ID and Google Workspace identities in practice. It is not SAML, there is no OIDC discovery against an arbitrary issuer, and there is no SCIM provisioning. That work is on the public roadmap as planned rather than in progress, and the roadmap entry was corrected downward in August 2026 specifically so this answer could not be misread.
They askCan a fast or passwordless sign-in method bypass MFA?
No. Every method funnels through one shared routine, and the MFA challenge is the last gate in it. An emailed link or a provider handshake replaces the password — not the second factor. While a challenge is pending the session is returned to unauthenticated, so there is no partially-signed-in state to exploit.
They askCan you require that our users sign in only through their work accounts?
Yes, as an organization-level policy. It refuses passwords and emailed links, because a link sent to an inbox is not your identity directory. The refusal is recorded with its own reason code, and it is evaluated only after the account is known to exist and be verified so the message cannot be used to enumerate addresses.
They askDoes provider sign-in automatically create accounts?
No. There is no just-in-time provisioning. An unrecognised address is refused and directed to an administrator. Accounts are created by invitation, and an allowed-email-domain policy is enforced at that point.
They askHow long is a passwordless credential valid, and can it be replayed?
Fifteen minutes by default, single-use, and stored only as a hash. The link token carries 32 bytes of randomness. Redeeming either the link or the paired code revokes the other. A credential is also invalidated if the account’s email address changes after it was issued.
They askDoes your sign-in page reveal whether an email address has an account?
No, by design and in every branch. A link request for an unknown address, an inactive account, or an address where the email itself failed to send all produce the same response. The one place we deliberately say more is when a code was revoked because its link was opened elsewhere — reaching that state requires having already spent the link, which means access to the mailbox.
They askWhat is recorded for authentication events?
Successful sign-ins, MFA challenges, link and code requests and redemptions, and each failure with a distinct reason — deactivated account, policy refusal, expired password, incorrect code, an address changed after issue. These are entries in the hash-chained audit trail rather than an application log.
The first row is the one to press us on. If your requirement is a SAML application in your own identity provider with SCIM deprovisioning, we are not there yet and a demo will not change that. The public roadmap carries it with a status we are willing to be held to, and the compliance matrix marks which of our control claims have been verified against the code and which have not.
What it is, and what it isn’t
“Single sign-on” means two different things depending on who is saying it, and the gap between them is exactly where a procurement process goes wrong six weeks in. Here is the line drawn where we would want it drawn if we were the ones evaluating.
Why the honest version is the useful one. A vendor who answers “yes, we support SSO” to the SAML question buys six weeks and loses the deal in week seven, when an engineer asks for the metadata URL. If provider sign-in with Google or Microsoft accounts meets your requirement, this is built, in production, and you can exercise it this afternoon in a free workspace. If it does not, you have that answer now.
Connected controls
Authentication answers who somebody is. These are the controls that decide what that person may reach, from which device, for how long, and what record it leaves.
Password rules and history, failed-login lockout, session idle and absolute limits, allowed email domains.
OpenRoles, granular permissions, MFA policy across your organization, and impersonation logging.
OpenDevice approval and IP allowlisting — the checks that ask where a sign-in came from, not just who it was.
OpenEvery authentication event lands in a hash-chained trail where an edited or deleted entry is detectable.
OpenFor staff who need a payslip or a leave balance rather than a workspace seat — a separate door with its own rules.
OpenRetention, sub-processors, data processing, and the verified-versus-unverified status of every control claim we publish.
OpenWhat changes
The usual trade in this area is convenience against control: every method you add to make signing in easier is another place a check can be missed. Funnelling all of them into one corridor is what makes that trade unnecessary.
A storekeeper who has forgotten a password gets in from an emailed code on a shared terminal, without a call to whoever holds the admin account.
Adding a faster route in does not create a quieter one. The challenge is the last gate on every path.
One check, ahead of every method — so removing someone does not leave a second door they still know about.
A spike of “provider required” refusals reads differently from a spike of wrong passwords, because the trail records which is which.
Identical answers for every address mean the login form is not a directory of who works for you.
Including on SAML, where the answer is no and is easier to plan around than a maybe.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
