Social sign-in lets a customer register and sign in with an account they already have. WBAMS ships three providers. Each one needs an application created at the provider, and each one needs a redirect URL that must match exactly.

All three are configured in the same place: Settings → Sign-In Integrations. Activate the provider, fill its two credential fields, tick Enabled, and save.

Get the redirect URL right before you start.

Every failure in this setup is a mismatched redirect URL. It must match character for character — scheme, host, path, and no trailing slash. Copy it from the table below rather than typing it.

The redirect URLs

Replace example.com with your own System URL, exactly as it is set in Settings → General.

ProviderRedirect / callback URL to register
Googlehttps://example.com/auth/provider/google_signin/finalize
Facebookhttps://example.com/auth/provider/facebook_signin/finalize
Twitterhttps://example.com/auth/provider/twitter_oauth/authorize
These must be HTTPS.

Google and Facebook both refuse plain HTTP redirect URLs for anything but localhost. If your System URL is still http://, fix that first or the provider will reject the application.

Google

You need a Google Cloud project with an OAuth client. It is free.

  1. Open the Google Cloud Console and select an existing project or create one for your site.
  2. Go to APIs & Services → OAuth consent screen. Choose External, then fill in the app name, your support email, and your domain. Add your site’s domain under authorized domains.
  3. Go to APIs & Services → Credentials and choose Create credentials → OAuth client ID.
  4. Set the application type to Web application.
  5. Under Authorized redirect URIs, add:
    https://example.com/auth/provider/google_signin/finalize
  6. Create the client. Google shows a Client ID and a Client secret — copy both now; the secret is easiest to retrieve at this moment.
  7. In WBAMS, open Settings → Sign-In Integrations and activate Google.
  8. Paste the values into Client Id and Client Secret, tick Enabled, and save.
Publishing status matters.

While the consent screen is in Testing, only the accounts you list as test users can sign in. Everyone else sees an access-denied screen that looks like a WBAMS fault and is not. Publish the app when you are ready for real customers.

Facebook

  1. Open Facebook for Developers and create an app. Choose the type that offers Facebook Login.
  2. Add the Facebook Login product to the app.
  3. In Facebook Login → Settings, add to Valid OAuth Redirect URIs:
    https://example.com/auth/provider/facebook_signin/finalize
  4. Open Settings → Basic and copy the App ID and App Secret. The secret is hidden behind a Show button and will ask for your password.
  5. Make sure the app has access to the customer’s email address. Without the email permission WBAMS cannot create or match an account.
  6. In WBAMS, open Settings → Sign-In Integrations and activate Facebook.
  7. Paste the values into App Id and App Secret, tick Enabled, and save.
  8. Switch the Facebook app from Development to Live. In development mode only app administrators can sign in.
A Facebook account without an email address cannot register.

WBAMS identifies the customer by email. Some Facebook accounts — phone-number registrations in particular — have no email to share, and those customers must register normally.

Twitter

  1. Open the Twitter Developer Portal and create a project and an app.
  2. In the app’s User authentication settings, enable sign-in and request read access with email.
  3. Set the callback URL to:
    https://example.com/auth/provider/twitter_oauth/authorize
  4. Copy the API Key and API Secret Key from the app’s Keys and tokens page.
  5. In WBAMS, open Settings → Sign-In Integrations and activate Twitter.
  6. Paste them into API Key and API Secret Key, tick Enabled, and save.
Twitter requires email access to be requested explicitly.

The permission is off by default and the app will otherwise return a profile with no email, which WBAMS cannot use to create an account.

Test it properly

  1. Open the client area sign-in page in a private browsing window, so you are not already signed in to the provider as yourself.
  2. Press the provider’s button. You should reach the provider’s consent screen, not an error.
  3. Approve, and confirm you land back in the client area signed in.
  4. Check the account was created with the right email address, then sign out and sign in again to confirm the second time matches the existing account rather than creating a duplicate.

When it does not work

redirect_uri_mismatch
The URL registered at the provider is not exactly the one WBAMS sent. Check scheme, host, path and trailing slash, and check your System URL in Settings → General.
The button does nothing
The provider is not Enabled, or the credentials are blank. Both are saved on the same form; saving credentials does not enable the provider by itself.
Access denied at the provider
Google in Testing mode, or a Facebook app still in Development. Publish or go Live.
Signed in but no account
The provider returned no email address. See the notes above for Facebook and Twitter.
Works for you, not for customers
Almost always the publishing status. You are an app administrator; they are not.