Security and shopper data
What Store Social Login asks for, stores and never touches
Store Social Login signs shoppers in with Google, Facebook, X and email code and then hands them to BigCommerce, which keeps the customer, the orders and the session. This page lists what the app asks a sign-in provider for, what it keeps, and what it leaves alone, so you can judge it before you request access.
The short version
Asked, stored, never touched
BigCommerce stays the system of record for your customer accounts. The app keeps only what it needs to recognise a returning shopper, sign them in and keep one store apart from another. The table describes Google sign-in and the email code.
| Kind of data | Asked from the sign-in provider | Stored by the app | Never touched |
|---|---|---|---|
| Who the shopper is | Asked from the sign-in providerGoogle’s account identifier, the verified email address and, when Google has them, the first and last name. | Stored by the appA connection between the shopper’s Google identity and the store’s BigCommerce customer ID. The identifiers and email addresses used for matching are stored as hashes. | Never touchedThe shopper’s Google password. Access to Gmail, Google Drive, contacts or payment information: the app does not ask for it. |
| Passwords | Asked from the sign-in providerNothing. A Google password stays with Google. | Stored by the appNothing. The app stores no customer password. | Never touchedThe app never receives a provider’s password and keeps no store password. The one store password it handles is the one a shopper chooses when they disconnect Google: it passes through the app’s server to BigCommerce and is not stored or logged. Password recovery stays on BigCommerce. |
| Email codes | Asked from the sign-in providerOnly the address the shopper types. The code is sent to it. | Stored by the appThe code records hold an HMAC of the code, made with a secret key held on the server, and a hash of a token that ties the code to the page that asked for it. The email that carries the code (the address, the subject and the body, with the code in it) is held by the app’s email service and its queue, and by the email delivery provider that sends it. The app deletes its copy a week after the email is sent; the provider keeps its own copy for 30 days, in the United States. | Never touchedThe code is never kept in the code records in readable form. It does travel in the email itself, so the copies of that email described above hold it. |
| Customers and addresses | Asked from the sign-in providerNothing beyond the identity items in the first row. | Stored by the appThe BigCommerce customer ID. When a sign-in needs a profile step, the Google profile is held encrypted for up to ten minutes and cleared once it is used or abandoned. | Never touchedA copy of your customers, their addresses or their profiles. BigCommerce keeps them; the app mirrors none of it. |
| Orders | Asked from the sign-in providerNothing from the provider. Only to attach past guest orders, the app asks BigCommerce for orders under the verified address. | Stored by the appNothing. No order data is copied. | Never touchedAn order that an existing customer account owns is never moved, whatever its email says. |
| The store and its staff | Asked from the sign-in providerNothing from a provider. BigCommerce sends a signed install message and a signed launch message when staff open the app. | Stored by the appThe store identifier, the permissions the store approved, its settings, the BigCommerce access token (encrypted and bound to that store) and the identifiers and short-lived sessions of authorised staff. | Never touchedThe access token and the signing keys never reach the browser. There is no separate merchant password to store. |
| Technical records | Asked from the sign-in providerNothing. | Stored by the appShort-lived sign-in attempts, replay records and rate-limit counters, cleared by a scheduled cleanup, plus daily counters of sign-ins and checkout health that hold no shopper data. Hosting infrastructure may process IP addresses and request metadata to operate the service and prevent abuse. | Never touchedGoogle user data is not sold, used for advertising or used to train AI models. |
The rows describe the way the app is built. The privacy policy covers Google sign-in, the email code and order access, and this page describes the same things in more detail. The email address is the one thing every method has in common, and the app treats it the same way whether Google or a code has proved it.
No second login system
How a shopper ends up in a normal BigCommerce session
Once a provider has said who the shopper is, the app does not run a parallel account system. It hands the shopper to BigCommerce and lets BigCommerce sign them in.
01
Shopper
Chooses a method on your store.
02
Sign-in provider
Verifies who they are and tells the app.
Account ID, verified email, name
03
Store Social Login
Matches or creates the BigCommerce customer.
BigCommerce customer ID
04
Login token
Signed with the app’s OAuth client secret.
Valid 30 seconds, one visit
05
BigCommerce
Checks the token and starts its own storefront session.
A native session
The mechanism is BigCommerce’s Customer Login API, opens in a new tab, which its documentation describes as a way to “enable single sign-on for storefront customers using the Customer Login API and JSON Web Tokens.” After the provider has verified the shopper, the app finds the matching BigCommerce customer, or creates one, and signs a short token with its OAuth client secret. The shopper’s browser is sent to a one-use address on your storefront domain, and BigCommerce checks the token and starts its own storefront session.
BigCommerce’s page sets the limits that make this safe to use. The token is a JSON Web Token signed with the app’s OAuth client secret, its issued-at time is valid for 30 seconds, and the address can be visited once. The page also states: “A customer account has a single active storefront session.” The client secret lives on the app’s server and never reaches a browser, and a leaked token is good for seconds and a single visit.
The result is an ordinary signed-in BigCommerce customer. The account page, saved addresses and order history are BigCommerce’s own, and the store’s own password form and password recovery keep working beside the new methods. The first time an existing customer signs in with Google, from anywhere except their account settings, the app has BigCommerce retire the old store password, so an account that someone else pre-registered under that address cannot keep a working password. A customer the app creates has no password until they set one.
The app asks the store to approve these BigCommerce permissions: Customers: Modify and Customer Login: Token Login to find or create the customer and start their session, Content: Modify and Checkout Content: Modify to add the storefront script (BigCommerce requires both for login, account and checkout pages), and, to attach past guest orders, Orders: Modify. The dashboard says so while a store has not granted one of them.
Email code
The code’s limits
For shoppers with no social account, a six-digit code proves the address the same way a provider’s verified email does.
6
digits
From the server’s cryptographic random number generator.
10
minutes
A code lives ten minutes and works once.
5
wrong tries
The fifth wrong entry cancels it, and a newer code replaces an older one.
1
page
Only the page that asked for it can use it. Reloading the page means asking again.
The code is made on the app’s server. The records the app keeps to check it hold an HMAC of the code, keyed with a secret held on the server, so a copy of those records cannot be brute-forced offline against the million possible values. The code is, of course, in the email itself, and that email, with the shopper’s address, is held by the app’s email service and its queue and by the email delivery provider that sends it. The app deletes its copy a week after the email is sent; the provider keeps its own copy for 30 days, in the United States. The storefront script also mints a random token for each sign-in and sends it with every step. The app keeps only its hash and refuses the code from any other page.
A code lasts ten minutes and works once. Five wrong entries cancel it, and requesting a new code replaces the old one. After a correct code the record stays usable for another ten minutes, so a new shopper can finish the name step.
Throttles
- One code per address every 30 seconds.
- Three codes per address and six per visitor every fifteen minutes.
- Ten verification tries per visitor a minute.
- A ceiling of 300 code requests a minute for the whole store.
The reply to a code request is the same whether or not the address has an account. The storefront does make one separate check, on the sign-in page and at checkout, before it sends a code: it asks whether the address has an account, so a typo is caught instead of becoming a new account. That answer is a single yes or no, throttled per visitor and per address. Whether an address has an account is already visible on a store’s create-account form and at checkout; whether it is linked to a provider is the new bit, and it is the part the throttle protects.
Store isolation
Each store is kept apart, and the tests check it
Here is what is enforced, what is tested, and where the limits are today.
The unit the app keeps apart is the BigCommerce store installation, identified by the verified store hash. It is not the merchant’s email address and not a global BigCommerce user ID: the same person can belong to several stores, and the same customer ID number can exist in two stores without joining their data. The data lives in shared database tables, with the boundary enforced by the application rather than by a separate database for each store. We say so plainly because it tells you where the checks live: in code, which is why they are tested.
Enforced
- A dashboard session carries the verified store, user and session. The server takes the store from that identity and ignores any store ID the browser sends.
- Sensitive backend functions need a short-lived server credential that browsers and merchants do not hold.
- Each store’s BigCommerce token is encrypted with a binding to that store, checked when it is decrypted.
- Google connections are keyed to a store and channel, and sign-in rate limits are kept per store.
Tested
- Two stores run side by side in one test database, with the same merchant ID, the same Google identity hashes and the same BigCommerce customer ID in both. Nothing joins up.
- Swapped session claims, and direct calls from anonymous, merchant or wrong-issuer callers, are refused.
- Repeated callback IDs and rate-limit keys stay inside their own store.
- Settings, staff removal, disabling, re-authorising and uninstalling one store leave the other alone.
Limits today
- The tests use synthetic stores, not real customer records.
- The app runs on a store’s primary storefront channel. Other channel setups and themes are not claimed.
- The server credential is deliberately powerful across stores, so Vercel and the app’s signing keys sit inside the trusted boundary.
- More real-store acceptance testing is planned before the app is offered more widely.
Merchant access
No separate login for the dashboard
You open Store Social Login from Apps in your BigCommerce control panel, with the access you already have.
BigCommerce sends a signed launch message when you open the app. The app checks the signature, the store, the user and the expiry, and refuses a message it has seen before. There is no merchant account, password or sign-up to create. The store owner changes the sign-in settings, and authorised staff can open the dashboard with their existing access.
The dashboard keeps its sign-in short-lived. In the browser it holds a five-minute token in memory, renews it while the dashboard is open and re-checks access each time, and ends the session after four hours at most. It uses no cookies and no browser storage, so reloading the page means opening the app from BigCommerce again. When BigCommerce tells the app that a staff user was removed, that user’s sessions end, and the data layer refuses their next request.
Leaving
What happens when you uninstall
Settings go at once, shopper links wait thirty days in case you come back, and your customers and orders are not touched.
Removed at once
- The store’s settings and its BigCommerce access token
- The store’s own Google client
- The sign-in address on the store’s domain, including from hosting
- The store’s counters
- Every dashboard session for the store
Kept for 30 days
- Shoppers’ Google links, so a reinstall inside the window finds every shopper still connected
- After 30 days a scheduled cleanup purges them
Never touched
- Customer accounts in BigCommerce
- Orders in BigCommerce
The thirty-day window exists for one reason: a reinstall inside it finds every shopper still connected, so nobody has to start again. Customer accounts and orders live in BigCommerce, so they are the same before and after.
Policy and contact
Where the privacy policy is, and who to ask
The formal statement of how data is handled is the privacy policy, which covers Google sign-in, the email code and order access, and names Vercel (hosting) and Convex (data) as service providers; a third provider sends the code email. A store’s own privacy policy separately governs its customer accounts, purchases and marketing, so you will want to keep that one current for your shoppers.
For access, correction, disconnection or deletion requests about the app, email support@storesociallogin.com. We may need to verify your identity and the store first. For setup help, see the support page: include your store’s public URL, and never send passwords, API secrets or sign-in links.
Everything on this page describes how the app works and what its automated tests cover. If you want to know something about how it handles your shoppers’ data that is not here, ask before you request access.
Questions about security and data
Does Store Social Login keep my shoppers’ passwords?
The app never receives a Google password and keeps no store password: BigCommerce keeps those, along with password recovery. When a shopper disconnects Google they choose a new store password; it passes through the app’s server to BigCommerce and is not stored or logged. The first time an existing customer signs in with Google, from anywhere except their account settings, the app has BigCommerce retire their old store password, so an account someone else pre-registered under that address cannot keep a working password. A customer the app creates has no password until they set one.
Does it keep a copy of my customers or orders?
It keeps no copy of your customer accounts or orders. BigCommerce stays the system of record for customers, addresses, orders and sessions. The app keeps the store’s installation and settings, sessions, hashed identity links to BigCommerce customer IDs, and counters. A sign-in that needs a profile step holds the Google profile encrypted for up to ten minutes. The one personal detail held in readable form is the address a shopper types to receive an emailed code, inside the email that carries the code, which the app deletes a week after sending (see the email code section).
Can one store see another store’s shoppers?
The app is built so that it cannot. Each store is its own tenant, the store comes from a verified identity rather than from anything the browser sends, and automated tests run two stores side by side to check that nothing crosses. The data sits in shared tables with the separation enforced in the application, and the tests use synthetic stores rather than real customer records.
Who can change the settings?
The store owner changes sign-in settings. Authorised staff can open the dashboard from the BigCommerce control panel with their existing access. There is no separate login to create.
Can a shopper disconnect Google?
Yes, from the account page on your store, which first asks them to create a store password. Disconnecting removes only that store’s connection and never deletes the BigCommerce customer. Removing the app’s access from a Google Account does not by itself delete the store account or the connection, so the account page is the place to do it.
Keep reading
- The short version of this page
How a sign-in travels from the shopper to BigCommerce, on the home page.
- BigCommerce passwordless login with an email code
How the six-digit code compares with BigCommerce’s own emailed link.
- Sign-in at BigCommerce checkout
What the shopper sees at each checkout state, and how guest checkout stays.
- How to add social login to BigCommerce
An app or a custom build: the constraints and a decision checklist.
- Show your store’s name on Google sign-in
Use your own Google client and a sign-in address on your domain.
- Google sign-in for BigCommerce stores
Sign in with Google on the login, create-account and checkout pages.
Give your shoppers a faster way in.
Store Social Login is in a private rollout, so access is by request. Tell us about your store and we will reply about getting sign-in onto your storefront.
Asking costs nothing and commits you to nothing. You will need your storefront address and, if you know it, your theme.