Skip to main content
Vito provides social authentication through a single JSON endpoint. The client handles the OAuth redirect and token exchange directly with the provider (e.g., using the Google Sign-In SDK), then sends the provider token and identity data to the API. The server validates the credentials, creates or matches the user account, and issues a Sanctum token.

Supported providers

Only providers in this whitelist are accepted. Requests with an unrecognised provider value are rejected with a 422 validation error.

Endpoint

Middleware: throttle:api

Request

string
required
OAuth provider name. Must be one of: google, facebook, apple, github, twitter.
string
required
OAuth access token issued by the provider. Maximum 4096 characters (enforced to prevent memory-exhaustion attacks).
string
required
The user’s unique ID within the provider’s system (e.g. Google subject ID). Maximum 255 characters.
string
required
Email address from the OAuth profile. Validated with RFC and DNS checks.
string
Display name from the OAuth profile. If omitted, the local part of the email is used.
string
URL to the user’s profile image. Maximum 2048 characters. Must be a valid URL.

Response — authenticated user

When the provider identity matches an existing account or a new account is created:
string
Sanctum token named social-api-token. Use it as a Bearer token in subsequent requests.
string
Either /dashboard for existing users or /onboarding if the account requires additional setup.

Response — onboarding required

If the social identity is new and the user needs to complete a profile:
The redirect_to value is set to /onboarding when AuthStatus::REQUIRES_ONBOARDING is returned by the domain handler.

How it works

The AuthController::socialLogin method constructs a LoginViaSocialProviderCommand from the validated request data and dispatches it to the LoginViaSocialProviderHandler:
The handler links the OAuth identity to an existing user by provider_id or email, or creates a new user record if neither matches.

Idempotency

The Idempotency-Key header is accepted but not strictly required. If omitted, the handler generates a UUID internally. Providing the key prevents duplicate account creation if the client retries a timed-out request.

Error responses