Social login
Google, Facebook, Microsoft and GitHub buttons on your form — the one option that adds to your sign-in method instead of replacing it.
- Intermediate
- 5 min read
- Applies to 2.0
It adds, it does not replace
Every other option on the Authentication tab replaces the site's sign-in method. Social login does not: it puts provider buttons on your sign-in form alongside whatever method is active. Password sign-in and a Google button can coexist.
The social login settings, with the four providers and the button placement options.
Four providers
| Provider | Needs |
|---|---|
| Client ID and secret from Google Cloud Console | |
| App ID and secret from Meta for Developers | |
| Microsoft | Application ID and secret from Azure |
| GitHub | Client ID and secret from your GitHub developer settings |
Each is configured independently — enable only the ones you want, each with its own credentials and redirect URL taken from the settings screen.
Microsoft's return address has a different shape, and the settings screen
shows it to you: a path, …/wp-json/attributes-pro/v1/social/microsoft, rather
than the query string the other three use. Entra ID allows a query string in a
redirect URI only for apps restricted to work or school accounts; this one also
accepts personal Microsoft accounts, and the portal refuses the other form
outright — URL may not contain a query string. Copy what the screen shows,
not what you copied for Google. It needs the Web platform, and a site that
is not on plain permalinks.
Web, not Single-page application. Azure offers both platforms and will accept your path under either, so this one is easy to get wrong and gives no sign of it until someone actually signs in. A SPA registration requires PKCE and a cross-origin exchange, which a WordPress site cannot make — the sign-in gets all the way to Microsoft, comes back, and fails with:
Proof Key for Code Exchange is required for cross-origin authorization code redemption.
If you see that sentence, open Authentication, delete the address from Single-page application, add a Web platform, and paste the same address there. Deleting it from SPA is the part that matters: with the URI listed under both, Azure treats it as SPA and nothing changes.
Four providers ship with the plugin. Older documentation lists three and omits Microsoft; the settings screen is the reliable list.
Test it before you trust it
Each provider has its own block on the settings screen, and its own Test this connection button. Pressing it saves what you typed, sends you to the provider to sign in once, and brings you back here with a verdict.
It is the real journey, and that is the point. Whether the secret is the right one, whether the return address is registered, whether the application sits under a platform allowed to redeem a code with a secret — none of it is visible until a code actually comes back and is exchanged. A configuration can look complete on this screen and refuse every visitor.
Nothing is created by a test, nobody is signed in to your site, and the profile the provider returns is read for its address and then dropped.
- Verified — the block folds to one line: the account it reached, and how long ago. It folds as soon as it passes, including on the page you land on immediately after testing.
- Failed — the block stays open with the provider's own explanation sitting above the fields you need to correct.
- Edited — changing a client ID or a secret forgets the verdict. It described the keys that earned it.
- Every provider you enabled shows as verified, not merely configured
- You tested with an account that does not exist on the site
The setting that decides who gets an account
Allow registration governs what happens when someone signs in with a provider and has no account here yet:
- On — an account is created from the provider's profile
- Off — only members who already have an account can use the buttons
Off is the default, and it is the right one for a private or paid site: turning it on means anyone with a Google account can create one on yours.
When the provider's email already belongs to someone
This is the other half of the same setting, and it is the half the label does not mention. If the address a provider returns matches an account that already exists here, the two can be joined — the visitor signs in as that member.
That only happens when the provider states it has verified the address:
| Provider | Verifies the address | Automatic linking |
|---|---|---|
| yes | possible | |
| GitHub | yes, for the address on file | possible |
| Microsoft | no such claim is returned | never |
| no such claim is returned | never |
And never for an administrator, whatever the provider says. An account that can change the site is not joined on the strength of an email address.
Where linking is refused, nothing is lost: sign in here first, then link the provider from your account. That path proves you hold the WordPress account, which is the proof an email address on its own does not give.
Every account link is written to the Audit Log, under Security. It is worth knowing where to find them: a link is a new way into an account, so the record of when one was added belongs next to the sign-ins themselves.
It also decides where the buttons appear. With it on, they sit on your sign-in form and your registration form — a visitor sent to either can start the same flow. With it off, they appear on the sign-in form only: a provider button on a registration page would send someone to Google and back to be told there is no account for them.
Placement and style
Buttons can sit above or below the form, in branded colours or a plain style that follows your theme. Above is the stronger nudge; below keeps the regular form as the main path. The choice applies to both forms.
- Each provider is tested end to end, with a real account
- The redirect URL registered with the provider matches the one shown here
- Allow registration is set the way you meant
- You have tested with an account that does not exist on the site
Related articles
Something missing or out of date? Tell support.