Configure these in Architect Panel → Security → Authentication Methods.
The general steps
- Register an application in the provider's own developer console.
- Set the redirect address there to the one shown on the Authentication Methods screen.
- Request the information you need — at minimum the user's identifier, usually their e-mail address.
- Enter the client ID and secret in Authentication Methods.
- Switch it on. Its tile appears on your login page.
Provider-specific points
- Apple needs a services ID, team ID, key ID and key file rather than a simple secret. It also lets users hide their real address behind a forwarding address, so do not assume you can mail them from anywhere else.
- Microsoft covers both personal and work accounts. For organisational sign-in with control over which tenant, configure Azure AD instead.
- GitHub may not release a verified e-mail address at all — handle its absence.
- Facebook and Instagram require app review before releasing e-mail addresses to a live application.
- LinkedIn restricts what an application may request; confirm what yours is approved for.
What a social sign-in actually tells you
It tells you the user controls that social account. It does not tell you their name is real, that they work anywhere in particular, or that they are over any age. Where you need to know one of those, pair the login with User Verification.
And who can now reach your login page
Do not enable a public social provider on an application that assumes its users are staff. Anyone with a Google account can then reach your sign-in. Decide what a brand-new external user is entitled to — usually nothing until approved — before you switch one on.
Worked Examples
- Consumer sign-up: Google and Apple cover most users; Apple is mandatory if you also ship an iOS app.
- Developer tool: GitHub sign-in, with an e-mail prompt for accounts that release none.
- Staff portal: Microsoft only, and social providers left off entirely.