Social sign-in

Sign in with GitHub, Google, or anything else Laravel Socialite drives.

Off until you name at least one provider. There is no half-configured state: with the list empty the routes do not exist and the login screen renders no buttons.

Turning it on

LARASPRING_AUTH_SOCIAL=github,google

Credentials are not configured in laraspring-auth. Each provider reads its client id and secret from Laravel's own config/services.php, exactly as Socialite documents. laraspring-auth only decides which providers are offered:

// config/services.php
'github' => [
    'client_id' => env('GITHUB_CLIENT_ID'),
    'client_secret' => env('GITHUB_CLIENT_SECRET'),
    'redirect' => '/oauth/github/callback',
],

That split is deliberate. Duplicating credentials into a second config file is how they end up out of sync, and it would put the kit between you and Socialite's own documentation.

The routes

Route name	Method	Path
oauth.redirect	GET	/oauth/{provider}
oauth.callback	GET	/oauth/{provider}/callback

The {provider} segment is constrained to the providers you enabled, so a provider you have not turned on is a 404 at the router, before any driver is built. Nothing leaks about which providers exist.

The login and register screens receive a socialProviders prop, which the editions render through components/social-login.tsx and SocialLogin.vue.

What the callback is allowed to do

Three cases, in the order they are tried:

1. The external identity is already linked. Sign that user in. Nothing else happens, and a changed display name at the provider does not overwrite anything here.
2. The address is new. Create a user. Their password is random and unknown to anyone, so the account is reachable only through the provider or a password reset.
3. The address already belongs to a user. Link the identity to that account, if and only if the provider says the address is verified.

The unverified address rule is the one that matters

If a provider hands back an address it has not verified and the kit linked it anyway, anyone who can create an account at that provider with your customer's email address takes over your customer's account. So an address reported as unverified is never linked, whatever link_by_email says, and the visitor is sent back to the login screen.

Providers disagree on how they report this. OpenID Connect and Google use email_verified; GitHub only ever returns an address it has already verified. The package reads email_verified, verified_email and verified from the raw payload, treats anything that explicitly says unverified as unverified, and trusts everything else, which is the bargain you accept by enabling a provider at all.

An identity with no email address at all cannot be signed in. There is nothing to key an account on, and inventing an address collides the moment a second such user arrives.

Turning off linking by email

'social' => [
    'link_by_email' => false,
],

With this off, case 3 above never happens: a provider address that already belongs to a user is refused outright, verified or not. Existing users then link their provider account deliberately rather than by signing in with it. Stricter, and more support tickets. Pick knowingly.

The link table

Linked identities live in social_accounts: one row per external identity, with a unique index on (provider, provider_id) so the same provider account cannot be attached to two users. The package migrates it itself and resolves your users table through the guard rather than assuming it is called users.