Wapu Auth – Social Login for WordPress and WooCommerce

Wapu Auth adds Google and Facebook social login to WordPress and WooCommerce. Provider OAuth processing is handled by the fixed Wapu Auth Broker at https://auth.wapuos.com; provider client secrets and provider tokens never enter WordPress.

On activation or update, Wapu Auth queues an asynchronous, one-shot background connection. An eligible public HTTPS site is registered, verified and checked without requiring a normal registration button click. The worker uses an expiring lock, reuses a pending broker challenge, retries temporary failures with bounded backoff and never rotates or re-registers a verified current-origin credential. Local, private, non-HTTPS and cloned origins fail closed. A protected manual retry remains available when the host, firewall or cron system needs attention.

After the connection is verified, the plugin checks local HMAC signing, broker provider availability, schema integrity, identity preflight and safe backfill before enabling new broker login starts. Existing WordPress users, roles, WooCommerce customers, orders and downloads are not recreated or deleted by this workflow.

Main Features

• Google and Facebook login through full-page broker redirects and a closed provider registry.
• Optional native Google One Tap/FedCM for signed-out visitors in compatible browsers, using a per-site public Web Client ID and the same canonical Broker identity mapping.
• Automatic background site registration and proof-of-control verification for eligible public HTTPS sites.
• Encrypted, non-autoloaded per-site broker credentials with exact-origin binding.
• HMAC-signed server requests with timestamps, fresh nonces and fixed broker paths.
• Independent, expiring local transactions for concurrent login attempts.
• Canonical provider identities with conflict-aware account linking and safe unlinking.
• Adaptive provider controls: one enabled provider uses a full button; multiple providers use accessible circular buttons.
• Shortcodes [wapu_auth_button] and [wapu_auth_login_button], plus the wapu-auth/login-button block.
• WooCommerce login, registration, checkout return, profile autofill and My Account integration.
• Active WordPress session management, including individual revocation and closing other sessions.
• Safe return URLs, domain rules and a local sandbox allowlist.
• Local multiprovider analytics for Google, Facebook and traditional WordPress access, with provider filters and sanitized exports.
• Optional detailed Activity Log, GeoIP enrichment and GA4 event bridge.
• Identity migration diagnostics, bounded safe backfill and non-destructive broker pause/resume controls.
• Site-scoped support conversations through the broker’s audited HMAC API.
• Optional private image attachments in Support, capability-gated by the broker and proxied without exposing site credentials.
• Native WordPress login remains available when allowed by the site’s configuration.

How Broker Login Works

1. A visitor selects Google or Facebook.
2. WordPress validates the return URL and creates an expiring, provider-bound local transaction.
3. WordPress sends a signed request to /api/v1/google/sessions or /api/v1/facebook/sessions.
4. The broker returns an allowlisted provider start URL and completes provider OAuth.
5. The broker returns a one-use wxc_* code to /wapu-auth/oauth/callback on the WordPress site.
6. WordPress consumes the local transaction and exchanges the code at /api/v1/oauth/exchange.
7. The plugin requires the returned provider and subject to match the local transaction before resolving, linking or creating the WordPress user.
8. WordPress issues its normal authentication cookies and applies the validated local return URL.

How Google One Tap Works

1. When One Tap is enabled, an eligible signed-out HTTPS visitor in a compatible browser may receive Google’s native account prompt on the current site. The regular Google redirect button remains available when Google does not display the prompt.
2. WordPress creates a browser-bound local transaction and requests a short-lived One Tap session from the Broker over the existing signed connection.
3. Google returns an ID-token credential to the page after the visitor selects an account. The browser sends that credential directly to the Broker’s exact, one-use, origin-bound endpoint; WordPress never receives it.
4. The Broker validates Google’s signature plus issuer, audience, authorized party, time, verified email and transaction nonce, then issues the same short-lived wxc_* code used by redirect login.
5. The browser navigates only to the site’s fixed local callback. The existing canonical resolver matches google/sub, establishes the WordPress session and returns the visitor to the validated same-origin URL.

Compatibility and Removed Features

The deprecated [wapu_auth_popup], [wapu_auth_popup_button], [wapu_auth_login_form] and [wapu_auth_register_form] aliases render the normal redirect control for compatibility. They do not open a popup or render a custom form.

Version 2.0 removed the original direct-token One Tap implementation, local modal authentication, emailed login links, email OTP, trusted-device bypasses and integrated SMTP configuration. Version 2.1 restores only native Google One Tap through the Broker-backed, nonce-bound flow described above. Popup/modal authentication and the other retired modules remain removed.

WordPress Multisite is not supported. Activation is stopped before identity migrations on a network installation.

Hooks & Filters

Actions

• wapu_auth_before_login — before a broker authorization session is created.
• wapu_auth_user_authenticated — after successful user resolution.
• wapu_auth_user_created — after a WordPress user is created.
• wapu_auth_provider_account_unlinked — after one provider mapping is removed.
• wapu_auth_google_account_unlinked — compatibility action after a Google mapping is removed.
• wapu_auth_analytics_event — after a local analytics event is recorded.
• wapu_auth_log — after the plugin logger records an entry.
• wp_login — standard WordPress action, fired exactly once for a successful broker login.

Filters

• wapu_auth_user_data — presentation fields only; provider identity fields remain immutable.
• wapu_auth_redirect_url — final redirect, subject to same-origin validation.
• wapu_auth_error_message — local user-facing error copy.
• wapu_auth_button_html — rendered provider control HTML.
• wapu_auth_geoip_enabled — optional GeoIP enrichment.

The legacy wapu_auth_auth_params, wapu_auth_redirect_uri and wapu_auth_oauth_base_url filters are compatibility notifications. They cannot change the broker host, callback, provider, state, nonce, signature, ticket or one-use code.

External Services

1. Wapu Auth Broker (required for social login)

Fixed origin: https://auth.wapuos.com

When used: after activation or update for background registration/verification and provider health; when a visitor starts or completes social login; when an administrator deliberately rotates a credential or uses the Support section.

Endpoints used:

• POST /api/v1/sites/register/init and POST /api/v1/sites/register/verify for proof-of-control registration.
• GET /health for a public, secret-free provider and One Tap capability snapshot.
• POST /api/v1/google/sessions or POST /api/v1/facebook/sessions to begin login.
• POST /api/v1/google/one-tap/sessions to create a signed, short-lived One Tap challenge.
• Browser OPTIONS/POST requests to the exact /api/v1/google/one-tap/credentials/{ticket} endpoint after a visitor selects a Google account.
• POST /api/v1/oauth/exchange to exchange the callback’s one-use code.
• Browser paths under /oauth/google/* or /oauth/facebook/* during provider authorization.
• Site-scoped /api/v1/support/* operations only when an administrator uses Support.
• Signed binary support-image upload plus private thumbnail/content delivery only when the broker capability flag is enabled.

Registration data: canonical site URL, fixed local callback URL, short-lived verification URL and registration identifier. The broker performs a public GET of the verification URL, which returns only the active short-lived challenge.

Login data: site ID, HMAC timestamp/nonce/signature headers, provider-bound local state, validated return context and the one-use exchange code. With One Tap, the browser additionally sends Google’s short-lived ID-token credential directly to an origin-bound Broker endpoint. The credential is validated in memory and is not stored or returned to WordPress. Sensitive protocol values are not written to plugin logs.

Identity data received: provider, provider subject, email and verification state, and optional name/avatar fields. Provider tokens, refresh tokens, provider authorization codes and provider client secrets are not returned to WordPress.

Support data: the subject, allowlisted category, public messages and optional JPEG/PNG/WebP evidence deliberately entered by an administrator. Images are normalized to remove EXIF/GPS and unnecessary metadata, remain in private broker storage and are returned only through authorized proxy requests. Internal broker notes and private agent data are not exposed to WordPress.

Documents: About | Privacy | Terms

2. Google Identity Services / OAuth / OpenID Connect

When used: redirect OAuth is contacted after a visitor selects the Google button. If an administrator enables One Tap and the Broker has not reported the capability as disabled, the versionless Google Identity Services script at https://accounts.google.com/gsi/client is loaded on eligible signed-out HTTPS pages so Google can decide whether to display its native prompt.

For redirect login, the visitor reaches Google through the Broker. For One Tap, Google returns the selected account’s ID-token credential to the page and the browser submits it directly to the Broker for nonce-bound verification. Google receives normal identity-service and browser/network metadata under its own policies. Provider access and refresh tokens are not returned to WordPress.

Policies: Google Privacy Policy | Google Terms

3. Meta / Facebook Login (indirect)

When used: only after a visitor actively selects Facebook.

The visitor reaches Facebook through the broker. Meta may receive normal OAuth request and browser/network metadata under its own policies. Provider tokens stay at the broker and are not returned to WordPress.

Policies: Meta Privacy Policy | Meta Terms

4. GeoIP providers (optional, disabled by default)

Services: https://ipapi.co/, with https://ipwho.is/ as fallback.

Data sent: visitor IP address and normal HTTP metadata.

When used: only when the administrator enables GeoIP enrichment. The site owner is responsible for an appropriate legal basis and consent where required.

Policies: ipapi.co Privacy | ipwho.is Privacy

5. Google Analytics 4 event bridge (optional, disabled by default)

The plugin can call a site’s existing gtag function with provider-aware social-login events and limited status metadata. It does not load Google Analytics itself. The site administrator is responsible for consent and the site’s Analytics configuration.

Privacy & Data Retention

Wapu Auth stores local configuration, the optional public One Tap Client ID, encrypted broker credentials, a one-way verified-origin fingerprint, hashed and expiring transaction state, canonical provider mappings, compatibility metadata, WordPress session data and any enabled analytics or Activity Log records. Depending on settings, detailed logs can contain account email, IP address and derived location.

The automatic-connection state contains only sanitized status codes, counters, timestamps, provider availability and a one-way origin hash. It never contains the broker challenge, registration ID, site secret, signature, request payload or remote response.

While one proof-of-control operation is pending, its registration ID and challenge are held separately in a short-lived WordPress transient only until verification, explicit recovery or expiry; they are not copied to plugin logs.

Wapu Auth does not store provider access tokens, provider refresh tokens, provider authorization codes, Google One Tap ID-token credentials, raw HMAC signatures, clear Broker tickets or one-use exchange codes. One Tap ticket and nonce hashes expire at the Broker and are deleted after use or pruning. Legacy Google Client ID/Secret values from 1.x are retained only in separate authenticated encrypted storage until an administrator completes the protected removal flow; only a valid public Client ID may be copied automatically into the active One Tap setting.

Optional GeoIP and GA4 features are disabled by default. Administrators should update their own privacy notice and select a retention period appropriate to their jurisdiction.

Optional Support images are disabled until the broker advertises the compatible WAPU-SUPPORT-ATTACHMENT-V1 capability. Pending images are temporary and pruned after expiry; linked images are retained only for the broker support workflow and removed under its ticket/site retention policy. They are not attached to WhatsApp or administrative email notifications. The broker strips EXIF, GPS and unnecessary image metadata during normalization. Site administrators should avoid uploading secrets or unrelated personal information and describe this support processing in their own privacy notice when the feature is enabled.