Guard Dog vs QRAuth – Passwordless & Social Login

Guard Dog is a focused WordPress security plugin for the login door, authentication, sessions, and practical access workflows. With custom login URLs, two-factor authentication, passkeys, CAPTCHA providers, access control, and activity logging, Guard Dog helps site owners tighten the parts of WordPress that get bothered most. Key Features: Custom Login URLs – Hide your wp-admin and wp-login.php from attackers Two-Factor Authentication (2FA) – TOTP-based authentication with recovery codes Social Login (OAuth) – Sign in with Google, Microsoft, or Apple Passkeys – Use device-based biometric authentication like Face ID, Touch ID or Windows Hello Multiple CAPTCHA Providers – Support for Google reCAPTCHA v2/v3, hCaptcha, and Cloudflare Turnstile Login Attempt Limiting – Prevent brute-force attacks with intelligent lockout Access Control – IP-based whitelist/blacklist protection Activity Monitoring – Comprehensive logging of security events Temporary User Access – Create temporary WordPress users with time-limited, secure access Frontend Account Security – Shortcodes and blocks for login, passkeys, 2FA, and session controls Why Choose Guard Dog? Privacy-Focused – Multiple CAPTCHA options including privacy-first providers WordPress.org Compliant – Built following WordPress coding standards Site-Owned Controls – Protections run inside your WordPress site User-Friendly – Intuitive interface with helpful documentation Regular Updates – Actively maintained and updated Perfect For: Business websites requiring enhanced security WordPress sites handling sensitive data Multi-user sites with complex access requirements Anyone wanting practical login and account protection without a central SaaS dependency Frontend Shortcodes: [guard_dog_login_form] renders a public Guard Dog-managed login form [guard_dog_passkey_login] renders a standalone passkey sign-in button for custom login pages [guard_dog_two_factor] renders logged-in 2FA management [guard_dog_passkeys] renders logged-in passkey management [guard_dog_sessions] renders logged-in active-session management [guard_dog_account_security] renders the composite logged-in account security widget for 2FA, passkeys, and sessions [guard_dog_2fa] remains supported as the legacy alias for the account security widget Block-based themes can use the matching Guard Dog Login Form, Passkey Login, Two-Factor Auth, Passkeys, Sessions, and Account Security blocks. Additional Information Support: For support questions, please use the WordPress.org support forums. Privacy: Guard Dog respects user privacy and offers multiple privacy-focused options. Third-party services are only contacted when you enable features that need them, such as CAPTCHA, email delivery, social login, IP reputation, or geolocation. Security: Guard Dog follows WordPress security best practices. User input is sanitized and output is escaped throughout the plugin. Third-Party Services Guard Dog integrates with the following third-party services to provide CAPTCHA protection. These services are optional and only used when CAPTCHA features are enabled. Google reCAPTCHA (v2 and v3) What it is: Google’s CAPTCHA service that helps protect websites from spam and abuse. What it’s used for: – Verifying that login, registration, and password reset attempts are made by humans – Preventing automated bot attacks on your WordPress forms What data is sent and when: – User interaction data (mouse movements, time spent on page) when CAPTCHA is solved – IP address of the user – Site domain for verification – CAPTCHA response token Privacy and Terms: – Google reCAPTCHA Privacy Policy – Google reCAPTCHA Terms of Service – Google reCAPTCHA Data Usage Cloudflare Turnstile What it is: Cloudflare’s privacy-first CAPTCHA alternative that doesn’t require user interaction. What it’s used for: – Invisible verification of human users during login, registration, and password reset – Privacy-focused protection without tracking or cookies What data is sent and when: – Non-interactive browser signals when forms are submitted – IP address for verification – Site domain for validation Privacy and Terms: – Cloudflare Privacy Policy – Cloudflare Terms of Service – Turnstile Documentation hCaptcha What it is: A privacy-focused CAPTCHA service that doesn’t track users across websites. What it’s used for: – Human verification during login, registration, and password reset forms – Privacy-conscious alternative to Google reCAPTCHA What data is sent and when: – User interaction with CAPTCHA challenge – IP address for verification – Site domain for validation Privacy and Terms: – hCaptcha Privacy Policy – hCaptcha Terms of Service – hCaptcha Data Processing Google OAuth (Social Login) What it is: Google’s OAuth 2.0 service that allows users to sign in using their Google account. What it’s used for: – Authenticating WordPress users via their Google account – Retrieving basic profile information (name, email) to link or create accounts What data is sent and when: – User is redirected to Google’s authorization server when clicking “Sign in with Google” – An authorization code is exchanged for an access token on your server – Basic profile information (name, email, Google user ID) is retrieved from Google’s API – No ongoing data sharing – data is only retrieved during the login process Privacy and Terms: – Google OAuth Privacy Policy – Google OAuth Terms of Service – Google API Services User Data Policy Microsoft Azure AD (Social Login) What it is: Microsoft’s OAuth 2.0 service via Azure Active Directory that allows users to sign in using their Microsoft account. What it’s used for: – Authenticating WordPress users via their personal Microsoft account or organizational (work/school) account – Retrieving basic profile information (name, email) to link or create accounts What data is sent and when: – User is redirected to Microsoft’s authorization server when clicking “Sign in with Microsoft” – An authorization code is exchanged for an access token and ID token (JWT) on your server – Basic profile information (name, email, Azure object ID) is extracted from the ID token – No ongoing data sharing – data is only retrieved during the login process Privacy and Terms: – Microsoft Privacy Statement – Microsoft Services Agreement – Microsoft Identity Platform Documentation Apple Sign In (Social Login) What it is: Apple’s OAuth 2.0 / OpenID Connect service that allows users to sign in using their Apple ID. What it’s used for: – Authenticating WordPress users via their Apple ID – Retrieving basic profile information (name, email) to link or create accounts What data is sent and when: – User is redirected to Apple’s authorization server when clicking “Sign in with Apple” – An authorization code is exchanged for an access token and ID token (JWT) on your server – Basic profile information (email, user ID) is extracted from the ID token – User’s name is only provided on first authorization; subsequent logins return only the user ID – Apple may provide a private relay email address instead of the user’s real email – No ongoing data sharing – data is only retrieved during the login process Privacy and Terms: – Apple Privacy Policy – Sign in with Apple Guidelines – Apple Developer Program License Agreement TOTP (Time-based One-Time Password) Standard What it is: An open standard (RFC 6238) for generating time-based one-time passwords used in two-factor authentication. What it’s used for: – Generating secure, time-limited authentication codes for 2FA – Providing backup authentication when primary 2FA methods are unavailable – Enabling compatibility with popular authenticator apps (Google Authenticator, Authy, Microsoft Authenticator, etc.) What data is sent and when: – No external data transmission – TOTP codes are generated locally using the TOTP algorithm – Secret key generation – A unique secret key is generated locally when 2FA is enabled for a user – QR code generation – QR codes are generated locally for easy setup with authenticator apps – Code verification – Generated codes are verified locally against the stored secret key Privacy and Terms: – RFC 6238 – TOTP Standard – Google Authenticator Privacy Policy (if using Google Authenticator app) – Authy Privacy Policy (if using Authy app) – Microsoft Authenticator Privacy Policy (if using Microsoft Authenticator app) Data Handling Summary When CAPTCHA is disabled: No data is sent to any third-party services. When CAPTCHA is enabled: Only the specific provider you choose receives verification data. Data is not shared between providers or stored by Guard Dog beyond the verification process. When 2FA is disabled: No external data transmission occurs. When 2FA is enabled: – All TOTP operations (code generation, verification) happen locally on your server – No data is transmitted to external services for 2FA functionality – Authenticator apps only receive the initial setup QR code or secret key – Recovery codes are generated locally and stored securely When Social Login is disabled: No data is sent to any OAuth provider. When Social Login is enabled: – Data is only sent to the configured providers (Google, Microsoft, Apple) during the login process – Only basic profile information (name, email, user ID) is retrieved – Social account links are stored locally in your WordPress database – Users can unlink their social accounts from their profile at any time User control: Users can choose which CAPTCHA provider to use, or disable CAPTCHA entirely. 2FA can be enabled/disabled per user, and users can choose their preferred authenticator app. Social login can be enabled/disabled by administrators, and users can manage their linked social accounts. All security features are optional and configurable.

QRAuth replaces the password field on your WordPress login page with a drop-in QR widget. Users sign in by scanning with the QRAuth mobile app; a cryptographic signature is verified server-to-server before WordPress sets the auth cookie. Social login (Google, GitHub, Microsoft, Apple) is brokered by QRAuth’s hosted approval page, so you never have to register an OAuth app or hold a client secret. One Client ID is the only configuration. Paste it into Settings → QRAuth and the widget appears on wp-login.php. Everything else — the approval flow, the signing, the token refresh — lives in the QRAuth platform. Account safety is the default. Auto-provisioning is off out of the box: only WordPress users who already exist (matched on email) can sign in via QRAuth. Flip on auto-provisioning and new users are created as Subscriber — that’s the only role available, intentionally and at every layer (settings UI, sanitiser, runtime). Operators who need a different role for an individual user can change it manually via Users → All Users after their first sign-in. The plugin never stores the signing material, never issues a redirect outside your site, and never touches your user table on uninstall. Self-hosted, no third-party scripts on wp-login.php. The QRAuth web component ships vendored inside the plugin — the only outbound call is from your server to QRAuth’s verification endpoint during a sign-in attempt. Open source build. The compressed JavaScript at assets/js/qrauth-components.js is built from publicly available TypeScript source at https://github.com/qrauth-io/qrauth/tree/main/packages/web-components. The unminified source files are also vendored alongside the minified bundle inside this plugin (assets/js/source/) for offline review. See the Source section below for build instructions. External services This plugin connects to QRAuth (https://qrauth.io) — the identity verification service that performs the actual passwordless / social sign-in. QRAuth is operated by ProgressNet, the publisher of this plugin. Without QRAuth there is no widget and no sign-in. What the service is and what it is used for QRAuth verifies that the user who scanned the QR code (or completed a social-provider flow on the hosted approval page) is the same person who initiated the sign-in on your WordPress site, then returns a signed assertion that the plugin uses to set the WordPress auth cookie. What data is sent and when Auth-session creation — when a visitor opens a page that hosts the widget (wp-login.php, the registration form, a shortcode-enabled page, or a WooCommerce sign-in form), the plugin’s same-origin REST proxy sends your Client ID, Client Secret (server-side only — never exposed to the browser), and the host page URL to https://qrauth.io/api/v1/auth-sessions. No visitor data is included in this request. Sign-in verification — when the visitor approves the sign-in (by scanning with the QRAuth mobile app or completing a social-provider flow on QRAuth’s hosted approval page), the plugin’s REST proxy fetches the verified result from https://qrauth.io/api/v1/auth-sessions/verify-result. The response carries the QRAuth user identifier and, when the email scope is allowed in Settings → QRAuth, the user’s email address. The plugin uses this only to locate or create the matching WordPress user; nothing beyond a hashed link reference is retained. Hosted approval page — when a visitor on a phone taps “Continue with QRAuth”, the browser navigates to https://qrauth.io/a/ to complete the social-provider flow. This is a standard cross-domain navigation initiated by the visitor. The vendored web component (assets/js/qrauth-components.js) is served from your own WordPress site — there is no third-party JavaScript on wp-login.php, and the component does not contact qrauth.io directly from the browser; all server-to-server calls are proxied via your site’s REST API. Service terms and policies Terms of Service: https://qrauth.io/terms Privacy Policy: https://qrauth.io/privacy Data Processing Addendum: https://qrauth.io/dpa List of Sub-processors: https://qrauth.io/subprocessors Source The compiled bundle at assets/js/qrauth-components.js carries the following banner header at the top of the file: ` /*! * @qrauth/web-components v0.4.1 * Vendored by qrauth-passwordless-social-login. Do not edit by hand. * * Source: https://github.com/qrauth-io/qrauth/tree/main/packages/web-components * License: MIT * npm: https://www.npmjs.com/package/@qrauth/web-components * Build: npm install && npm run build:assets (see bin/fetch-web-components.mjs) * * The unminified TypeScript source for this bundle is also vendored at * assets/js/source/ — see assets/js/source/README.md for provenance. */ ` The unminified TypeScript source files are also vendored alongside the compiled bundle inside this plugin (assets/js/source/) for offline review. The plugin’s own source — PHP, the small browser adapter (assets/js/qrauth-adapter.js), build scripts, tests, and CI — is publicly maintained under GPL-2.0-or-later at: Plugin source repository: https://github.com/qrauth-io/qrauth-passwordless-social-login The PHP and assets/js/qrauth-adapter.js shipped in the plugin ZIP are non-minified — read them directly without checking out the repo. The vendored file assets/js/qrauth-components.js is a pinned production build of the public @qrauth/web-components library. The non-compiled source for that library is openly available: Source repository: https://github.com/qrauth-io/qrauth/tree/main/packages/web-components (MIT-licensed) npm release: https://www.npmjs.com/package/@qrauth/web-components — pinned to v0.4.1, sha512 in package.json under the qrauth.webComponentsIntegrity key Build instructions for the upstream library: https://github.com/qrauth-io/qrauth/blob/main/BUILDING.md To regenerate the vendored bundle from the pinned npm release, clone the plugin source repository linked above and run from its root: npm install npm run build:assets The build script bin/fetch-web-components.mjs (kept in the plugin source repository, not in the WordPress.org plugin ZIP) downloads the npm tarball, verifies its sha512 SRI hash against package.json#qrauth.webComponentsIntegrity, extracts the IIFE build, and writes it to assets/js/qrauth-components.js. CI runs the same script before the WordPress.org plugin-check job, so the bundle distributed on the directory always matches the published npm release. To rebuild from upstream source instead of the pinned tarball, follow BUILDING.md in the upstream library repository above.