Social and external login

Social login means signing in to one service using an account you already hold somewhere else — the Continue with Google button you have clicked on a hundred websites. It is popular because it removes a password, and it is a genuinely reasonable thing to want for a small company with no directory of its own.

This article is short and mostly negative, and that is the honest shape of it. Two providers are implemented and no others. The configuration surface that would let you switch either of them on does not exist yet. And even when it does, social login interacts badly enough with the rest of the platform's security that we would not recommend it for most business accounts. All three of those points are explained below, with what to do instead.

Which providers are supported

Google and GitHub. That is the complete list. There is no Microsoft, Apple, Facebook, LinkedIn, Slack or Okta social connector, and a request naming any of them is refused before anything else happens:

If you want to sign in with a Microsoft work account, that is not social login — Entra ID is a full identity provider and the right route is OIDC or SAML federation, which carries your Conditional Access policies with it. Reaching for the social connector to solve a Microsoft 365 problem would be a downgrade even if it worked.

The current state, precisely

The mechanism is written. A start endpoint redirects to Google or GitHub, a callback endpoint receives the authorisation code, exchanges it, reads the profile, finds or creates the matching user and issues a session. All of that is real code.

What is missing is the row it needs. A social connector requires a stored configuration for your organisation — the client ID, the client secret and the redirect URI issued to you by Google or GitHub. There is no API endpoint and no console page that creates one. The database table exists, the code that would read and write it exists, and nothing is mounted on the web surface that reaches it. So the first thing every attempt hits is:

GET /api/v1/iam/social/{provider}/start?org_id=...

400  social provider not configured for this organization
400  social provider is disabled
400  org_id query parameter is required

Two further limits are worth knowing, because they would still be there on the day the configuration surface lands and they change how you should think about the feature.

• The state value is held in one server's memory. The API runs as several replicas behind a load balancer. A person who starts the flow on one replica and comes back to another will be told invalid or expired state, because the second replica never saw the first one issue it. Federated sign-in state has to be shared, the way the SAML replay guard is, and here it is not.
• A social sign-in does not run the multi-factor step. The password login path checks whether the account has a second factor enabled and stops to ask for it before issuing a session. The social callback issues the session pair directly. Whatever your policy says about a second factor, a social sign-in would not honour it. This is the single most important sentence in the article and it is why we are in no hurry to finish the feature.

Your account security becomes theirs

Set the implementation aside and consider the design. When you allow social login, the security of a Qorionix account stops being a property of Qorionix and becomes a property of the social account. Whoever can get into that Google or GitHub account can get into this one. Every control you configured here — the second factor, the lockout after five failed attempts, the password policy — is bypassed, because none of it is on the path any more.

That trade is fine when the social account is itself a managed corporate identity with enforced multi-factor authentication and a leaver process. It is not fine when it is a personal account. A personal Google account belongs to the person, not to the company: you cannot enforce a second factor on it, you cannot see its sign-in history, and on the day that person leaves you cannot disable it. Your offboarding step becomes ask them nicely.

There is one more consequence specific to how accounts work here. A person who signs in socially and has no account yet is created as a user, but is not given membership of your organisation. A user with no membership holds no role, and a user with no role holds no permission at all — they can authenticate and then see nothing, which is confusing rather than dangerous, but it is not the joining experience anyone wants. Roles and permissions explains why membership rather than the user record is what carries authority here.

When social login is reasonable, and when it is not

How this interacts with your MFA policy

Multi-factor authentication in Qorionix is enforced at the point a session is issued. The login path looks at whether the account has a factor enrolled, and at whatever your sign-on policies require, and returns a challenge instead of a session when either says so. A second factor is only a control if every path that can produce a session goes through that check.

The social path does not. It issues the session directly. So a social connector, if enabled, would be an unenforced path around your MFA policy — and an attacker who compromises the social account never sees your second factor at all. This is precisely the failure mode that makes people distrust single sign-on generally, and it is the reason the feature is not finished rather than merely unpolished.

What to do instead, today

1. Turn on a second factor for every account. It is the single highest-value change available to you and it takes minutes. Set up two-factor authentication.
2. If you have a real identity provider, federate to it rather than to a social account. Single sign-on with SAML covers the standard most corporate providers still speak; Single sign-on with OIDC covers the newer one and is honest about which direction is finished.
3. Get accounts from your directory rather than from a sign-in button. SCIM inbound provisioning creates and deactivates people automatically from your HR system, which solves the leaver problem that social login makes worse.
4. For applications that cannot federate at all, read Apps without SSO support rather than handing out a shared password.

If social login is genuinely the right answer for your organisation — you have no directory, your staff all hold managed Google Workspace accounts, and you would rather federate to Google than run passwords here — tell us. That is a legitimate configuration and knowing that a real customer wants it is what moves it up the list. How to get help.