# Hybridauth 3.13: a PHP abstraction layer over social sign-in providers

> Hybridauth wraps Facebook, Twitter and Google behind one PHP interface so your app talks to a single class instead of five SDKs. The trade-off is that the wrapper is only as current as its provider adapters.

**hybridauth/hybridauth** — Open source social sign on PHP Library. HybridAuth goal is to act as an abstract api between your application and various social apis and identities providers such as Facebook, Twitter and Google.

- Repository: https://github.com/hybridauth/hybridauth
- Website: https://hybridauth.github.io/
- Stars: 3,386 · Forks: 1,102
- Language: PHP
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/hybridauth-hybridauth

## The adapter problem Hybridauth is built to absorb

Adding social sign-in to a PHP application usually means three integrations, not one. Facebook, Twitter and Google each ship their own SDK, each with its own authentication flow, its own token object and its own profile shape. Every one of those SDKs is a dependency you upgrade on someone else's schedule. The README states the goal plainly: Hybridauth acts as "an abstract api between your application and the various social apis and identities providers such as Facebook, Twitter and Google."

That abstraction is the whole product. The audience is a PHP developer who already has a login system and wants a social button next to it, without adopting three vendor libraries. The repository's topics list facebook, google, twitter and social-login, which matches the scope. It is not an identity platform, it does not store users for you, and it does not manage sessions beyond what PHP Session already provides.

## How the provider classes and the shared flow fit together

The architecture visible in the repository is a provider directory under src/ with a class per network, and the README example instantiates one directly: Hybridauth\Provider\Twitter. You pass a config array with a callback URL and a keys array holding key and secret, then call authenticate(). From there the same object exposes getAccessToken(), getUserProfile() and apiRequest().

The data flow is a conventional OAuth round trip wrapped in a class. The callback URL in your config is where the provider sends the user back, and the library completes the exchange there. Because every provider exposes the same three methods, your application code does not branch on which network the user picked. The README's example ends with apiRequest('statuses/home_timeline.json'), which shows the escape hatch: when the abstraction does not cover something, you pass a raw provider endpoint path through the same object.

That escape hatch is also the honest boundary of the design. The common surface is authentication and profile retrieval. Everything past that is provider-specific and leaks through as a URL string.

## Installing Hybridauth with Composer and running a first provider

The installation section recommends Composer, calling it "the now defacto dependency manager for PHP", and points to the GitHub releases page as the alternative for a manual download. The package name on Packagist is hybridauth/hybridauth, which is also how it appears in the repository path.

```bash
composer require hybridauth/hybridauth
```

After that, the README gives this configuration and call sequence for Twitter. The callback value must be the URL your application actually serves, and the key and secret come from the provider's developer console, not from Hybridauth.

```php
$config = [
    'callback' => 'https://example.com/path/to/script.php',
    'keys' => [
        'key' => 'your-twitter-consumer-key',
        'secret' => 'your-twitter-consumer-secret',
    ],
];

try {
    $twitter = new Hybridauth\Provider\Twitter($config);
    $twitter->authenticate();

    $accessToken = $twitter->getAccessToken();
    $userProfile = $twitter->getUserProfile();
}
catch (\Exception $e) {
    echo 'Oops, we ran into an issue! ' . $e->getMessage();
}
```

What you should see: authenticate() redirects the visitor to the provider, and on return getAccessToken() yields the token while getUserProfile() yields the profile object. The README wraps the whole block in a try/catch and prints the exception message, which is a reasonable default because provider failures surface as exceptions rather than return values.

The repository also ships an examples/ directory with example_01.php through example_07, which is the fastest way to see a working configuration without writing one from scratch. The requirements section lists PHP 5.4+, PHP Session and PHP cURL.

## Where the abstraction breaks down

The provider set is the first limitation. The README names Facebook, Twitter and Google as the examples, and the topics list repeats those three. If your product needs a network outside the shipped provider classes, the abstraction does not help you; you are writing an adapter against whatever provider base class exists in src/ and maintaining it yourself.

The second limitation is the release cadence of the adapters. A provider changing its API is not something this library can prevent. The practical consequence is that a broken sign-in flow is fixed by upgrading hybridauth/hybridauth, not by upgrading a vendor SDK at a moment you choose. The recent releases show how that plays out: v3.12.1 on 2025-04-22, v3.12.2 on 2025-06-18, and v3.13.0 on 2026-04-02. The last push to the default branch was on 2026-04-02, roughly six months before today. That is a real gap to weigh if you are starting a new integration now.

Third, this is not the right tool if you want a hosted identity service with user records, account linking and an admin console. Hybridauth returns a profile and a token. Persisting users, matching them to existing accounts and deciding what happens on a duplicate email address are all your application's problem, and the README does not address any of it.

## Hybridauth against using provider SDKs directly

The real alternative is not another abstraction library. It is installing each provider's own SDK and writing the branching yourself. The difference in approach is where the coupling sits. With the SDKs, your application code knows about Facebook's client class, Twitter's client class and Google's client class, and each one is upgraded independently. With Hybridauth, your application code knows about one provider class and one set of method names, and the coupling moves into a single Composer dependency.

That trade is good when the providers you need are the ones the library ships and when you would rather have one upgrade than three. It is bad when you need a provider the library does not cover, because you pay the abstraction cost without getting the abstraction benefit. It is also bad when a provider's SDK gives you capabilities the common interface cannot express, since you end up calling apiRequest() with raw endpoint paths anyway.

A second reference point is the 2.x line. The README's version table lists 2.x as Maintenance, 3.x as Development, and 4.x as Future with PHP 7.3 and no repository or documentation yet. If you are on 2.x, the table is telling you where new work goes.

## Licence and the cost of keeping providers current

The README states that the Hybridauth PHP Library is released under the terms of the MIT License, and points to COPYING.md for the full copyright notice and disclaimer. The repository metadata reports the licence as NOASSERTION rather than a standard identifier, so if licence terms matter to your review process, read COPYING.md itself rather than relying on the metadata field. Nothing here is legal advice.

The upgrade cost is the part worth budgeting. Because providers are classes inside the library, every provider API change is a library release, and staying current means tracking those releases and re-testing each sign-in flow you support. The CHANGELOG.md at the repository root is where those changes are recorded. If you only enable one provider, that cost is small. If you enable several, a single upgrade can touch all of them at once, and you should plan to re-run each flow against a real provider account after any version bump.

## Conclusion

Adopt Hybridauth when you are adding social sign-in to an existing PHP application and want one interface across providers instead of vendoring each provider's SDK. Do not adopt it if you need providers outside the shipped set, or if you cannot accept that a provider API change lands as a library release rather than an SDK update you control. Before committing, verify three things: which providers your application actually needs and whether they exist under src/Provider, that your runtime has PHP Session and PHP cURL as the requirements section states, and whether the licence file COPYING.md matches what your legal review expects, since the repository metadata does not declare a standard licence identifier.

## FAQ

### How do I install Hybridauth in a PHP project?

The README recommends Composer, and the package is hybridauth/hybridauth. It also notes that you can download the latest release from GitHub instead. The stated requirements are PHP 5.4+, PHP Session and PHP cURL.

### Which social providers does Hybridauth support?

The README names Facebook, Twitter and Google as the identities providers it abstracts, and the repository topics repeat those three. The repository keeps one class per provider under src/, and the examples/ directory shows working configurations.

### What does the callback key in the Hybridauth config do?

The README's config array sets callback to the URL the provider returns the user to, alongside a keys array holding key and secret. You then construct the provider class with that config and call authenticate().

## Sources

- [hybridauth/hybridauth on GitHub](https://github.com/hybridauth/hybridauth)
- [Issues](https://github.com/hybridauth/hybridauth/issues)
- [Project website](https://hybridauth.github.io/)
- [README](https://github.com/hybridauth/hybridauth/blob/master/README.md)
- [Releases](https://github.com/hybridauth/hybridauth/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hybridauth-hybridauth