Documentation

WebProCMS can let dashboard users sign in with their Google Workspace or Microsoft 365 account instead of (or alongside) a password. It's a free, built-in feature — there's no separate on/off switch and no membership required. It's simply dormant until an admin sets up a provider on the Admin Sign-In settings page, and it's built so that turning it on can only ever add a convenient sign-in door, never weaken an account.

What it does

When enabled and configured, the dashboard login page shows "Continue with Google" / "Continue with Microsoft" buttons under the password form. A user clicks one, authenticates with the provider, and lands in the dashboard — no password to type. For organizations on Google Workspace or Microsoft 365 (where the org already enforces 2FA), this delegates the second factor to the provider: the user's existing Workspace MFA protects the dashboard for free.

Users can also link a provider to their existing account from the account menu → Settings → Connected Accounts, then sign in with it from then on. Their password keeps working either way.

The safety guarantees

The feature is deliberately conservative, because social sign-in is just another door into a privileged account:

• Accounts are never auto-created. A social sign-in only ever logs in to a user an administrator has already added. An unknown email is bounced to the login page, never provisioned. New team members are added the normal way (Dashboard → Users), then they can sign in with Google/Microsoft.
• It can't bypass two-factor authentication. If the matched user has authenticator-app 2FA enabled, a social sign-in is still sent through the same 6-digit challenge a password login would hit. Connecting Google never becomes a way around someone's second factor.
• Linking can't be hijacked. A provider account that's already connected to one user can't be silently re-pointed at another.
• Disconnecting never strands an account. Dashboard users always keep a password, so removing a social link always leaves a way back in.

Configuration

An admin sets it up in one place — Dashboard → Settings → Admin Sign-In: paste the OAuth Client ID and Client Secret for Google and/or Microsoft, and switch each provider on. The page shows the exact redirect/callback URL to register in the provider's OAuth app. Credentials live in the database, not in code or .env. As soon as one provider is enabled, the "Continue with…" buttons appear on the login page.

Two policy controls shape sign-in behavior:

• Allowed email domains (optional) — restrict sign-in to one or more domains (e.g. yourcompany.com). Only verified emails on those domains may sign in. Pointing this at your Workspace/365 domain is how you turn "we hope they have 2FA" into "the org enforces 2FA." Leave blank to allow any domain.
• Allow first-time sign-in by matching email (default on) — when on, a social sign-in is matched to the existing user with the same verified email and linked automatically on first use. When off, a user must connect the provider from their own settings before they can sign in with it (the strictest, fully user-chosen posture). Either way, no account is created. "Verified" is enforced, not assumed: an email the provider doesn't attest as verified (e.g. a Google account whose address was never confirmed) is never used for matching.

How it compares to email "magic links"

A code or link emailed at login adds no real security, because the password-reset flow already goes to the same inbox — so control of the email is control of the account regardless. Google/Microsoft sign-in is different: it can carry the user's provider-enforced MFA and never touches a one-time email link (so it isn't broken by corporate link-scanners that pre-fetch URLs). It's the convenient door that can also be a strong one.

Summary