Skip to Content
πŸ” Faable AuthSocial LoginOverview

Social Login

Social login lets your users sign in with an account they already have β€” Google, GitHub, Microsoft β€” instead of creating a new password. In Faable Auth, each provider is a social connection: you register an app with the provider, paste its client ID and secret into the Faable DashboardΒ , and enable the connection on your client. Faable handles the OAuth handshake and returns standard OIDC tokens, so your app code is identical regardless of which provider the user chose.

Built-in providers

These have their upstream endpoints preconfigured β€” you only supply credentials.

ProviderConnection typeShared Faable appSetup guide
Googlegoogle_oauth2βœ…Configure Google
GitHubgithubβœ…Configure GitHub
Microsoft (Entra ID)microsoftβœ…Configure Microsoft
Figmafigmaβ€”Bring your own OAuth app

Shared Faable app means you can switch the connection on without registering anything with the provider β€” useful to get moving, though the consent screen then shows Faable rather than your company. Fill in your own Client ID and Secret to take it over.

Any other provider

For anything not in the table above, create a Custom OAuth2 connection (custom) and supply the upstream values yourself: Authorize URL, Token URL, User Info URL and your credentials. Faable runs the same Authorization Code flow against them.

The one constraint: the provider’s userinfo response must expose the profile under the keys id, name, email and picture, as strings. Custom connections use the generic mapper β€” there is no per-provider normalization β€” so a provider that returns user_id, or nests the avatar in an object, lands with those fields empty. id is the one that must be present; without it the login fails outright.

Worked examples: Facebook. Providers that require a non-standard client authentication scheme β€” notably Sign in with Apple, which needs the client secret to be a signed ES256 JWT β€” are not supported through this path yet.

Don’t confuse this with the oidc connection type, which is a different thing entirely: it registers an external OIDC issuer whose JWTs Faable will trust in a Token Exchange β€” GitHub Actions being the canonical case. It drives no browser login, which is why the dashboard files it under Machine to Machine rather than Social Login.

How it works

  1. Register an app with the provider (e.g. a Google OAuth client) and copy its client ID and secret.
  2. Create a social connection in the Faable Dashboard and paste those credentials.
  3. Enable the connection on the client that runs your login flow.
  4. Log in. Send users to the /authorize endpoint β€” they pick a provider on the Universal Login screen, or you can target one directly with connection_id=connection_abc123. Faable normalizes the result into standard OAuth 2.0 / OIDC tokens.

Last updated on