Adding a Social Login
Social logins are configured per provider with credentials you obtain from that provider.
Where to find it
Architect Panel → Security:
- Authentication Methods — which sign-in routes are enabled
Architect Panel → Integration & Connections:
- OAuth Tokens — tokens issued through these routes
You register with the provider
Each provider requires you to register an application in their developer console and gives you an identifier and a secret. Those go into the sign-in method's configuration here.
The arrangement is between your organisation and that provider, on their terms — which is worth knowing when their terms change.
Redirect addresses must match exactly
The provider will only send users back to addresses you registered with them, matched exactly. This is the commonest configuration failure, and the usual causes are a trailing slash, http against https, or a development address left in place.
Remove development addresses before going live. A local address registered on a production application is a real hole.
Ask for the minimum
Providers show users what you are requesting. Asking for broad access to somebody's account when you need their name and e-mail address will be refused by people who read it — reasonably — and may attract additional review from the provider.
Request identity and nothing else unless you have a specific need.
Secrets expire
Most providers issue secrets with an expiry, and an expired one breaks sign-in completely for everybody using that route, on a date you knew in advance. Diary the renewal.
Matching to an existing account
The decision to make before enabling: when somebody signs in with a social provider using an address that already has an account, what should happen?
Linking automatically on a matching address is convenient and depends on trusting that the provider verified it. Creating a second account is safer and produces duplicates and confused users.
Whichever you choose, choose it deliberately — this is where a second route causes trouble.
Test the whole journey
Register through the provider as a genuinely new user, then sign in again as a returning one. Both paths, because they differ, and the second is the one that reveals identity-matching problems.
Have an alternative
Somebody will lose access to their social account. If that is their only route in, they lose your service too — through no fault of yours and with nothing you can do.
Let people add a password or a passkey, and make sure you hold an address you can reach them at.
Worked example
An organisation enables Google sign-in, requesting name and e-mail only, with exactly two redirect addresses registered and the development one removed before launch. Matching to an existing account is on, since the address is verified by the provider. Users are prompted to add a passkey after first sign-in, so nobody depends on Google alone.
Recommendations
- Exact redirect addresses, development ones removed.
- Request identity only.
- Decide the account-matching behaviour before enabling.
- Give users a second route in.