Google & Passkey
No-backend visitor sign-in — Google (FedCM) and passkeys (WebAuthn)
If you don't have a backend to sign tokens, the widget can sign visitors in itself — with Google or with passkeys. Both run inside the widget panel.
Google sign-in
When you enable Google, the widget renders a Google sign-in button, runs Google Identity Services in-panel, and forwards the resulting id_token to the backend, which verifies it against your OAuth client id.
Set it up
- Create an OAuth client id in the Google Cloud console.
- Add Wexio's widget origin to the project's Authorized JavaScript origins (
https://wexio.io, or your white-label domain). - In the Brand editor under Surfaces → Visitor authentication, enable Sign in with Google and provide the client id.
The backend verifies the token's signature, expiry, and — critically — that its audience matches your configured client id. Unverified Google emails are ignored. The client id is public by Google's design; no client secret is used or stored.
Pre-supply a Google token
If your host already has a Google id_token, pass it directly:
<WexioWidget
publicKey="pk_live_..."
user={{ googleIdToken: "<google-id-token>", name: "Ada Lovelace", email: "ada@example.com" }}
/>Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Sign-in does nothing | Google not enabled, or client id empty | Enable Sign in with Google under Surfaces → Visitor authentication and provide the client id |
| Sign-in fails verification | Audience mismatch, expired token, or backend clock skew | Confirm the configured client id matches the token's audience; check server time |
Passkey sign-in
Passkeys (WebAuthn) give visitors passwordless sign-in backed by their device — Touch ID, Face ID, Windows Hello, or a security key. Enable Passkey sign-in under Surfaces → Visitor authentication.
Two ceremonies run entirely in the widget:
- Registration — the visitor creates a passkey, anchored to a random handle that syncs across their devices (iCloud Keychain, Google Password Manager).
- Authentication — on return, the visitor signs in with that passkey.
The relying party is the embedding site
The passkey's relying-party id is derived from the embedding origin, validated against your allowedOrigins. Credentials are scoped to (integration, credential) — a passkey created on one integration can never authenticate on another.
Passkeys work in in-page embeds (React, Web Component) where the widget shares the host origin. For the iframe (script loader) embed, the host page must delegate WebAuthn to the iframe via an allow="publickey-credentials-get; publickey-credentials-create" permission policy — a documented v1 limitation.
Pinned profile fields
A verified sign-in pins the fields the proof carried, so the visitor can't edit them in the Profile tab:
| Proof | Pins |
|---|---|
| name, email (if verified), avatar | |
| Signed JWT | whatever the token signed (name / email / phone / fields.*) |
| HMAC | nothing |
| Passkey | nothing |
Pins are recomputed on every identify — if your host stops sending a claim, the field becomes editable again.