Laravel Socialite: OAuth logins for the nine providers Laravel ships adapters for

What Laravel Socialite actually removes from your codebase

OAuth is a redirect dance with a signature, a temporary token, a callback, and an access token exchange. Written by hand, that is several hundred lines of HTTP client plumbing per provider, and each provider differs in how it names its endpoints and what it puts in the user payload. Socialite replaces that with a fluent call chain. You redirect the user to the provider, the provider sends them back to your callback route, and you ask Socialite for the user.

The package is for PHP developers inside a Laravel application. It is not a general OAuth library you can drop into Symfony or a plain PHP script without the framework's service container behind it. The README describes it as providing an expressive, fluent interface to OAuth authentication, and the repository layout confirms the shape of that promise: a src/ directory of provider drivers and a tests/ directory alongside them.

The README is explicit about scope in a way that matters more than the feature list. It names Bitbucket, Facebook, GitHub, GitLab, Google, LinkedIn, Slack, Twitch and X, and then states: "We are not accepting new adapters." That single line tells you what this project is. It is a maintained set of first-party drivers, not a platform for adding your own upstream.

The redirect, callback and user exchange

The mechanism has three stages. First, your application sends the browser to the provider's authorization page. Socialite builds that URL, including the scopes you request and the callback it will return to. Second, the provider redirects back to your callback route with a code or token in the query string. Third, Socialite exchanges that value for an access token and fetches the user profile, handing you an object you can read fields from.

Underneath sits the OAuth 1 and OAuth 2 work. The description calls Socialite a "Laravel wrapper around OAuth 1 & OAuth 2 libraries", which is the honest framing: the signing and token exchange are delegated, and Socialite's contribution is the Laravel-facing API and the per-provider driver. That delegation is why the package can cover providers that still use OAuth 1 without you learning two signing schemes.

State handling is the part teams most often get wrong when they hand-roll this. Without a state parameter checked at the callback, an attacker can feed your callback a code that belongs to their own account. Socialite's flow is designed around that round trip, but the documentation you should read for the current details is the Laravel website, not the README, which only links out. Treat the README as an entry point and the Laravel docs as the reference.

Installing Socialite and completing a first GitHub login

The README does not print an install command. It points to the Laravel website for documentation and links the Packagist page, where the package is published as laravel/socialite. Installation goes through Composer, and the README's own badge links confirm the package name. After that, the Laravel documentation is where the configuration lives: you register the provider's client ID, client secret and redirect URL, then define two routes, one that redirects to the provider and one that receives the callback.

The README does not reproduce the driver call, the route definitions or the user object's fields. It names the providers and states that the package provides an expressive, fluent interface to OAuth authentication, and it directs readers to https://laravel.com/docs/socialite for the actual API. If you are evaluating the package without opening that page, you will not find the configuration keys or the scope syntax here.

What to expect once you have followed that documentation: the redirect route sends the browser to the provider's consent screen, and after approval the provider returns the browser to your callback route, where Socialite hands you the user object. The driver name you pass must match one of the providers Socialite ships, and the redirect URL registered with the provider must match the callback route exactly, including scheme and trailing slash, or the provider will reject the exchange.

If your provider is not one of the nine, the README points to the community driven Socialite Providers website, which lists adapters maintained outside this repository.

Where Socialite is the wrong choice

The adapter policy is the first real limitation. Nine providers are covered. If you need Apple, Discord, Microsoft or any regional identity provider, you are outside the official set, and the README's refusal to accept new adapters means that will not change through an upstream pull request. The community Socialite Providers site is the documented escape hatch, but those adapters are maintained by other people, on their own release cadence, and they are not covered by the tests in this repository.

Second, Socialite is an authentication helper, not an identity system. It gives you a user object from the provider. It does not decide whether that user is allowed into your application, does not link a provider account to an existing local account, and does not handle the case where the same person signs in through two providers. That logic is yours to write, and it is where most of the real complexity in a social login feature actually lives.

Third, the README is thin by design. It links to the Laravel website for documentation and does not reproduce configuration keys, scope syntax or the user object's fields. If you are evaluating the package without opening the Laravel docs, you will not find the answers here. The repository does carry an UPGRADE.md and a CHANGELOG.md, so version-to-version changes are traceable, but the README will not tell you what changed.

Socialite against the community Socialite Providers adapters

The most direct alternative is not a different OAuth library. It is the Socialite Providers ecosystem the README itself names. Both approaches use the same Socialite core, so the difference is not in the API you call but in who maintains the driver and where it lives.

An official adapter ships in this repository, is exercised by the tests directory here, and moves with the package's own releases, which the release list shows arriving on a roughly weekly cadence through August and September 2026. A community adapter is installed separately, is versioned separately, and its correctness is the responsibility of its maintainers. That is a real trade-off rather than a formality: an upstream change to Socialite's driver contract can require the community adapter to catch up, and you are the one waiting.

A second alternative is writing the OAuth exchange yourself against a general-purpose OAuth library. That gives you control over providers Socialite will never cover, at the cost of implementing the redirect, state check, token exchange and profile fetch for every provider you support, and re-implementing them when a provider changes its API. For one unusual provider, that may be the right call. For GitHub and Google, it is work you would be doing badly.

Maintenance, upgrades and the MIT licence

The repository is not archived, and its last push was on 2026-09-04. The most recent release in the list is v5.31.0, dated 2026-09-01, following v5.30.1 on 2026-08-25 and v5.30.0 on 2026-08-18. Development is concentrated on the 5.x branch, which is the default branch. For a package whose job is to track third-party OAuth endpoints, that release rhythm is the relevant signal: providers change their APIs, and a wrapper that stops moving becomes a wrapper that breaks.

Upgrade cost is bounded by the presence of UPGRADE.md and CHANGELOG.md at the repository root. Major-version migrations are documented there rather than in the README, so a team planning an upgrade should read UPGRADE.md before touching composer.json. Within a major version, the release numbering suggests patch and minor releases arrive without ceremony.

The licence is MIT, stated in the README and present as LICENSE.md. MIT is permissive: it allows commercial and closed-source use, modification and redistribution, subject to the licence terms. This is a description of the licence identifier, not legal advice, and if your organisation has policies about attribution or dependency review, route it through whoever handles that.

Editorial conclusion

Adopt Socialite if your Laravel application needs login through one of the nine providers it ships adapters for, and you want the redirect and callback flow handled without writing OAuth boilerplate. Do not adopt it expecting a new provider to be merged upstream: the README states clearly that new adapters are not being accepted, so anything outside the official list means the community Socialite Providers site. Before wiring it into production, verify the redirect URL registered with your provider matches the callback route exactly, check whether the provider you need requires OAuth 1 handling, and read UPGRADE.md for the 5.x migration notes.

Frequently asked questions

Official sources

1. laravel/socialite on GitHub
2. License: MIT
3. Project website
4. README
5. Releases