About Authentication
Authentication in AlloyScan determines who is allowed to sign in to a site, how their identity is established, and how machine-to-machine clients access the REST API. Sign-in is per-site: each site has its own user list, its own SSO configuration, and its own set of API clients (App registrations).
This page explains the model and the rationale. For step-by-step setup, see the SSO How-tos. For the field-level specification, see the Authentication Reference.
How authentication works
AlloyScan supports three coexisting paths for proving identity. They can all be enabled at the same time on the same site.
Email and password (native). The default sign-in surface. The user types their email and password on the sign-in page and is authenticated against the AlloyScan IdentityServer. The user's record on the site (Admin Center > Site Settings > IAM > Users) must exist and be set to Active = Yes. A self-service Forgot password? link is on the sign-in page, and signed-in users can change their own password from Manage your account > General.
Single sign-on (SSO). AlloyScan can delegate user sign-in to an external identity provider. Two providers are configurable per site:
- Microsoft — uses a Microsoft Entra ID (Azure AD) tenant App registration.
- Google — uses a Google Cloud OAuth client.
When a provider is enabled, a Sign in with Microsoft or Sign in with Google button appears on the AlloyScan sign-in page. The user clicks the button, authenticates on the provider, and is redirected back to AlloyScan with a token. The user's email must match an Active user record on the site for the sign-in to complete.
App registrations (machine-to-machine). For programmatic API access — for example, an Alloy Navigator instance pulling inventory through AlloyScan Sync — AlloyScan issues OAuth client-credentials grants. Each App registration has a Client ID, a Client secret, an expiration date, and an enabled flag. The client uses the credential pair to obtain a token and call the REST API directly, without an interactive user.
Why this design
Delegating SSO to the provider lets organisations centralise identity policies, group membership, and conditional access rules in one place — usually Microsoft Entra ID or Google Workspace. AlloyScan does not duplicate that policy surface.
Multi-factor authentication is a direct consequence of that delegation. AlloyScan does not surface a native MFA enrolment flow. If your SSO provider enforces MFA, that MFA enforcement applies at sign-in time, before the provider returns control to AlloyScan. For email-and-password accounts, MFA is not part of the AlloyScan native flow.
Note: Details may vary by deployment.
Per-site isolation matches AlloyScan's multi-tenant model. Users, App registrations, and SSO configuration belong to a site. A user with the same email on two sites is two separate user records, and an MSP administrator who manages multiple tenants moves between them via the site switcher in the header.
Key distinctions
- User authentication is interactive. It produces a browser session for a human user. It is the path used for the AlloyScan sign-in page, including SSO provider buttons. It is governed by the Admin Center > Site Settings > IAM > Users list and (when SSO is enabled) by SSO providers.
- App registrations are non-interactive. They produce access tokens for service-to-service or API access. They are managed at Admin Center > Site Settings > IAM > App registrations. App registrations have no role; their permissions follow the API surface they call. They are not used by human users to sign in.
A site usually has both: human users sign in with email and password or SSO; one or more App registrations exist for integrations such as AlloyScan Sync. The two surfaces are managed independently.
Limitations
- Native MFA is not part of AlloyScan. MFA is enforced through the SSO provider when one is configured.
- The set of supported SSO providers is Microsoft and Google. Other providers (SAML, Okta, Facebook, and others) are not supported.
- Visibility of the SSO providers menu entry depends on deployment-level configuration. On a deployment where the surface is not enabled, the entry is hidden for every site and SSO cannot be configured from the Admin Center.
- App registrations expire on a configured date. An expired registration produces a persistent "API client alert" banner on every page until it is renewed or disabled.