Sign-in and security

Shoppers can create an account and sign in on the storefront with their email and password, or with Google or Facebook. This page covers the Authentication group of tabs: Social Login, Turnstile, Sessions and API Access. Every credential on this page lives in WordPress, never in the storefront’s own configuration.

Before you start

• The Storefront URL is set on the General tab. The setup guides use it to show you the exact addresses to paste into Google and Facebook.
• Your storefront runs on HTTPS. Facebook sign-in doesn’t work without it.
• For Google: a Google account that should own the credentials (preferably a company account).
• For Facebook: a Meta developer account.
• For Turnstile: a Cloudflare account.

Check the sign-in secret

StoreFront›Settings›Authentication›Social Login

The banner at the top of the Social Login tab shows whether the secret that every storefront sign-in depends on, RSC_JWT_SECRET, is in place. It applies to email sign-in too, not just Google and Facebook.

Banner	Meaning
Green: “JWT signing secret is configured”	All good. The secret is defined in wp-config.php; it is never stored or shown in wp-admin.
Amber: “JWT signing secret is not configured”	Nobody can sign in or register on the storefront yet. The banner shows a ready-to-paste define( 'RSC_JWT_SECRET', '…' ); line with a freshly generated secret and a Copy button.

1. If the banner is amber, click Copy.

2. Send the copied line securely to whoever manages the server, and ask them to add it to wp-config.php above /* That's all, stop editing! */.

3. Reload the Social Login tab. The banner turns green.

Set up Google and Facebook sign-in

StoreFront›Settings›Authentication›Social Login

Each provider has a card. A provider’s button appears on the storefront’s sign-in and register pages as soon as its card shows Connected and you’ve saved. There’s nothing to redeploy. Only Google and Facebook are offered; Apple sign-in is not available.

Each card links to a built-in, step-by-step setup guide inside wp-admin (How do I get a Client ID? and How do I get an App ID and Secret?). The guides show the exact addresses for your store. You can also open them directly at admin.php?page=retail-store-companion#guide-google and #guide-facebook.

Google

Takes about five minutes. Google needs only a Client ID; no client secret is used.

1. Open the Google Cloud console (console.cloud.google.com), signed in with the account that should own the credentials.

2. Create a project, or choose one, in the picker at the top.

3. Fill in the consent screen (APIs & Services › OAuth consent screen, or Google Auth Platform › Branding): user type External, an app name (shoppers see it, so use your store’s name), a support email and a developer contact.

4. Go to APIs & Services › Credentials › Create credentials › OAuth client ID and choose the type Web application.

5. Under Authorised redirect URIs, add your storefront’s address followed by /login, for example https://shop.example.com/login. No trailing slash and no language prefix; it must match character for character. Add one entry for each address your storefront answers on. Authorised JavaScript origins can stay empty.

6. Create the client and copy the Client ID only. Ignore the client secret.

7. In wp-admin, paste it into Client ID on the Google Sign-In card and click Save Changes. The card shows Connected, and the Google button appears on the storefront.

Setting	What it does	Default
Client ID	Shows the Google button on the storefront’s sign-in and register pages. WordPress also checks every Google sign-in against this ID.	Empty

Google’s Testing publishing status doesn’t restrict who can sign in, so you don’t have to publish the app before shoppers can use it.

Facebook

Takes about ten minutes. Facebook needs an App ID and an App Secret. The button appears only when both are saved.

1. Open the Meta developer dashboard (developers.facebook.com/apps) and choose My Apps › Create app.

2. Give the app a name and contact email, choose the use case “Authenticate and request data from users with Facebook Login” and answer no to the games question. A business portfolio is optional.

3. Under the Facebook Login product, open Settings and set Login with the JavaScript SDK to Yes.

4. Add your storefront’s bare domain (for example shop.example.com, with no https:// and no path) to Allowed Domains for the JavaScript SDK. Valid OAuth Redirect URIs isn’t used and can stay empty.

5. Under App roles › Roles, give yourself a role so you can test. While the app is in development mode, only people with a role can sign in.

6. Under App settings › Basic, copy the App ID, then click Show next to App Secret (Meta asks for your password) and copy it.

7. In wp-admin, paste both into the Facebook Login card and click Save Changes.

8. When you’re ready for real shoppers, switch the app to Live. Meta requires a privacy policy address and a data-deletion instructions address first.

Setting	What it does	Default
App ID	The public ID the storefront uses to show the Facebook button.	Empty
App Secret	Used only by WordPress, to confirm with Facebook that a sign-in was issued for your app. Never leaves WordPress. Write-only: once saved, the field stays blank; leave it blank to keep the saved value.	Empty

Caution

Never put the Facebook App Secret into the storefront’s configuration or anywhere a browser can read it. It belongs only in this field (or in wp-config.php as RSC_FACEBOOK_APP_SECRET).

Rules shoppers meet

These are built in and can’t be changed:

• Staff use their password. Staff accounts, such as administrators and shop managers, can’t sign in with Google or Facebook. This protects your most powerful accounts.
• Facebook needs a password once to link. If a Facebook sign-in uses an email that already has an account, the shopper enters that account’s password once to link them. Facebook doesn’t confirm that an email address is verified, so this check prevents account takeover.
• Shoppers can disconnect providers from their account’s security page, as long as they keep at least one way to sign in.

Troubleshooting social sign-in

Symptom	Likely cause	What to do
No Google or Facebook button	A Client ID, App ID or App Secret is blank, or the storefront can’t reach WordPress	Check the card shows Connected, then wait up to 5 minutes.
Google shows Error 400: redirect_uri_mismatch	The redirect address in Google doesn’t exactly match	Add your storefront address plus /login, character for character.
Facebook says “JSSDK option is not toggled”	Login with the JavaScript SDK is off	Set it to Yes (Facebook step 3).
Facebook says “URL Blocked” or “Can’t load URL”	The storefront’s domain isn’t allowed	Add the bare domain (Facebook step 4).
Facebook works for you but not for others	The app is still in development mode	Switch it to Live (Facebook step 8).
The Facebook button does nothing	A pop-up blocker, or the storefront isn’t on HTTPS	Allow pop-ups; use HTTPS.
A shopper is asked for a password after choosing Facebook	Account linking, by design	They enter their existing password once.

Protect forms with Cloudflare Turnstile

StoreFront›Settings›Authentication›Turnstile

Turnstile is Cloudflare’s free, mostly invisible alternative to a CAPTCHA. It keeps bots off the storefront’s public forms.

1. In your Cloudflare dashboard, open Turnstile and add a widget. Add your storefront’s domain as a hostname.

2. Copy the widget’s Site Key and Secret Key.

3. In wp-admin, open the Turnstile tab and switch on the Cloudflare Turnstile card.

4. Paste the Site Key and the Secret Key, then click Save Changes.

5. Check that each form you want protected has its own Require Cloudflare Turnstile switch on (see the table below). They’re on by default.

Setting	What it does	Default
Card toggle	The store-wide master switch.	Off
Site Key	The public key the storefront uses to show the check.	Empty
Secret Key	Used by WordPress to verify each check with Cloudflare. Write-only: leave it blank to keep the saved value.	Empty

Which forms are protected. Turnstile checks only these forms, and only while the master switch is on and both keys are saved:

Form	Who is checked	Its own switch (on by default)
Product reviews	Everyone	Product page tab
Replies to reviews	Guests only	Same switch as reviews
Contact page message	Everyone	Pages › Contact tab
Back-in-stock (“notify me”) sign-up	Guests only	Stock alerts tab

Sign-in, registration, password reset and checkout are not protected by Turnstile.

Warnings the card can show:

• “Turnstile isn’t active until both keys are saved.” The switch is on, but a key is missing. Until both are saved, no check is made.
• “The saved secret key is the same as the site key…” Paste the real secret key from Cloudflare.
• “Cloudflare rejected the secret key … so shoppers could not be checked…” Cloudflare refused the secret. Paste the correct one; the warning clears after the next successful save or check.

Secret key equals site key

If you paste the site key into the Secret Key field, the whole save is refused with “The Turnstile secret key is the same as the site key… nothing was saved.” Nothing on any tab is saved until you fix it.

If Cloudflare can’t be reached, protected forms are refused rather than let through, and shoppers see “We could not verify you are human right now. Please try again.”

See who is signed in

StoreFront›Settings›Authentication›Sessions

The Sessions tab lists Active customer sessions: everyone currently signed in to the storefront, and on which devices. It’s read-only and has no Save button.

• The summary reads, for example, “12 active sessions across 9 customers”.
• Search by name or email… filters the list (press Esc to clear it).
• Each person has a card with one row per session:

Column	Shows
Device	Device and browser, for example “iPhone · Safari” (“Unknown device” if it can’t be told)
IP address	The address the sign-in came from. Because sign-in passes through the storefront’s server, this is often the server’s address rather than the shopper’s.
Signed in	The date the session started
Last used	How long ago it was last used, for example “2 hours ago”
Expires	When the session ends

Note

Despite the “customer” wording, the list includes every signed-in account, staff included. Signing people out from this screen isn’t available. A shopper who changes their password on the storefront is signed out on their other devices, and resetting a forgotten password signs them out everywhere.

Review API access

StoreFront›Settings›Authentication›API Access

This tab is a security setting for developers: it decides which WooCommerce APIs need a signed-in shopper. Most stores keep the defaults. The banner explains the rule: “Requests to protected namespaces need a valid Bearer JWT (or a first-party admin cookie). Public routes below are carve-outs that skip the JWT check. Consumer keys are always rejected.”

Setting	What it does	Default
Protected namespaces	WooCommerce API areas that need a signed-in shopper, one per line. Requests without a valid sign-in are refused.	wc/v3 (accounts and orders). The Store API, wc/store/v1, stays open.
Public routes	Exceptions inside a protected area: an HTTP method plus a path pattern that stays open. Add route adds a row; the × removes one. In paths, * means “any characters”.	Empty
Apply storefront preset	Replaces the whole Public routes list with three entries: product reads, the cart and checkout in the Store API. Only useful if you protect wc/store/v1. Takes effect after you save.	—

Don't clear Protected namespaces

If you empty the Protected namespaces box and save, the empty list is kept: no area is protected, and the default doesn’t come back by itself. Type wc/v3 back in and save to restore it. Path patterns of just *, /* or / are dropped without a warning, so they can’t open everything.

Next steps

Accounts and sign-inWhat shoppers see when they register and sign in.

Customers and engagementWishlist, compare, stock alerts and the newsletter.

Security and performanceHow the storefront protects shoppers and stays fast.

Colors and dark modeMake the storefront look like your brand.