# HWIOAuthBundle: 59 OAuth providers for a Symfony login flow > A Symfony bundle that turns OAuth1.0a and OAuth2 into a Symfony security authenticator, with a provider list long enough that the real question is which ones are actually maintained. MIT licensed, three releases in fifteen months, and explicit about its breaking changes. **hwi/HWIOAuthBundle** — OAuth client integration for Symfony. Supports both OAuth1.0a and OAuth2. - Repository: https://github.com/hwi/HWIOAuthBundle - Stars: 2,362 · Forks: 783 - Language: PHP - License: MIT - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/hwi-hwioauthbundle ## What the bundle actually adds to Symfony The README states the scope in one sentence: the bundle adds support for authenticating users via OAuth1.0a or OAuth2 in Symfony. A note underneath expands on why both exist, saying the bundle adds an easy way to implement any of OAuth1.0a or OAuth2 provider. That matters more than it sounds. OAuth2 is the current standard, but a meaningful number of APIs still speak OAuth1.0a, and the older scheme has different signing, different token handling and no standard scopes. A bundle that covers both means one integration surface rather than two, and the provider classes abstract away which one a given service expects. The interesting part is what the bundle does not do. There is no user table, no account linking strategy, no profile storage and no admin UI. It plugs into Symfony's security system as an authenticator, which means your existing user provider, password hasher, session handling and firewall configuration continue to do their jobs. That is the difference between this and a bundle that wants to own your user table. The repository structure reflects a conventional Symfony bundle: a src directory, a tests directory, a docs directory, a composer.json, plus phpstan.neon for static analysis, phpunit.xml.dist for tests and .php-cs-fixer.php for code style. There is also a SECURITY.md, which is worth noting in a package whose entire job is handling credentials. ## Fifty-nine providers, and the question that list raises The README claims support for 59 providers and then lists them. It is a long list, and reading it carefully is the fastest way to understand what this project is for. The obvious names are there: Apple, Facebook, GitHub, Google, Instagram, LinkedIn, Slack, Spotify, Twitch, Twitter, XING and Youtube. But the list is weighted toward services a general developer rarely logs into: 37signals, Asana, Bitly, BufferApp, Clever, Dailymotion, Deezer, DeviantArt, Discogs, Disqus, Dropbox, EVE Online, FI-WARE, Flickr, Foursquare, Genius, Hubic, Jawbone, JIRA, Mail.ru, Odnoklassniki, Office365, QQ, RunKeeper, Salesforce, Sensio Connect, Sina Weibo, Soundcloud, Stereomood, Strava, Toshl, Trakt, VKontakte, Windows Live, Wordpress, Yahoo and Yandex. The self-hosted and enterprise entries are the ones that usually decide the question. Auth0, Azure, Box, Google Cloud adjacent services, Itembase, Keycloak, Passage and Amazon Cognito all appear, which means the bundle is as useful for authenticating against your own identity provider as against a social network. What the list does not tell you is which entries are actively tested. Some of these providers have changed or restricted their APIs in recent years, and a provider class being present in a README is not a claim that the provider still works. That distinction is the one you cannot resolve without reading docs/index.md and testing against the service you actually need. ## Two years of releases that keep raising the floor The release history is short and unusually candid, and it is where the project's character shows. Three releases are recorded in the recent history. Version 2.3.0, published on 2025-01-01, dropped support for Symfony 6.3 and 7.0, added an Amazon Cognito resource owner, and shipped four bugfixes. Those fixes are more interesting than the feature: preventing overwriting `failure_path` in the AuthenticationFailureHandler when connect functionality is not enabled, preventing overwriting `failure_handler` in security configuration if it was already set, type hinting `AuthenticatorInterface` instead of `OAuthAuthenticator` in the RefreshAccessTokenListener, and adding missing parameters to the Odnoklassniki resource owner. Each is a case where the bundle was interfering with configuration you had already made, which is the classic failure mode for a security bundle. Version 2.4.0 on 2025-05-29 added PHP 8.4 test coverage, a LinkedIn OpenID resource owner and a `show_dialog` option to the Spotify resource owner. It also switched nonce generation to a CSPRNG, which is a security improvement that arrived quietly. Version 2.5.0 on 2026-02-19 is the current release and the most consequential. It adds PHP 8.5 test coverage and Symfony 8.0 support, handles absolute URLs in Amazon Cognito, and fixes a wrong HTTP status code in RegisterController. It also carries three backward-incompatible changes: raising `firebase/php-jwt` support to 7.0, dropping support for Symfony below 6.4, and dropping support for PHP below 8.3. One release raising the PHP floor from wherever it was to 8.3 is a real upgrade cost for anyone on an older stack. The README states the current requirement as PHP `^8.3` with Symfony `^6.4`, `^7.4` and `^8.0`. ## The documentation is the actual product Here is the shape of this repository in one observation: the README is roughly a page and a half, and almost none of it is instructions. Installation is delegated entirely. The README says all installation instructions are in the documentation and links to docs/1-setting_up_the_bundle.md for the current 2.x version, then points at docs/index.md as where the bulk of the documentation lives. What follows in the README is the provider list, the license, and a set of CI, Packagist and license badges. That is unusual for a Symfony bundle, where the convention is a README with a working quickstart. Most maintainers do this because the configuration surface of a security bundle is genuinely too large to fit in a README: resource owners, authenticators, the connect flow, firewall configuration, token storage, and the difference between authenticating an existing user and connecting an account. Trying to compress that produces a tutorial that breaks on the first real application. The practical consequence is that you cannot evaluate this bundle from the repository's front page. You need to open the docs directory, and specifically the setting-up page, before you can judge whether the configuration model fits your application. The README is a signpost rather than a manual, which is defensible but does mean the first thirty minutes of evaluation happen outside the repository. The MIT license is stated plainly, both in the README and in the LICENSE file, with no restrictions beyond attribution and warranty disclaimer. ## How this compares to league/oauth2-client The obvious comparison is with league/oauth2-client, the standalone OAuth2 provider library that many Symfony projects wire up themselves through a small amount of glue code. The difference in approach is where the work lives. league/oauth2-client is a toolkit: you configure a service provider, build an authenticator, wire it into your firewall. HWIOAuthBundle is the wiring, already done, for a large catalogue of specific services plus both protocol versions. What you get from the bundle is that the provider list is solved. Apple, Salesforce, Twitch, Keycloak, Amazon Cognito and fifty-odd others arrive with a resource owner class and the authorization URLs, token endpoints and scope names each service expects. Handling Spotify's `show_dialog` option or Amazon Cognito's absolute URLs is not your problem, because someone already fixed it in a release. What you give up is control over the integration's shape. If your application needs unusual behaviour in the login flow, you are working inside someone else's configuration model, and the bugfixes in the 2.3.0 release notes are a good illustration of the edges: the bundle was writing values into security configuration you had set, and had to be corrected to stop. For three well-known social providers, the toolkit plus your own authenticator is less machinery and more flexibility. For a long tail, or for a self-hosted identity provider, the bundle is the cheaper path by a wide margin. ## Conclusion HWIOAuthBundle makes sense for a Symfony application that needs login through providers the framework has no built-in support for, particularly the long tail beyond Google, such as Salesforce, Twitch, EVE Online or Office365, or when a Keycloak or Amazon Cognito instance is already in place. It is the wrong choice if you want social login with three providers, since Symfony's own security layer plus two or three league/oauth2-client providers is less machinery. The README is thin, so read docs/1-setting_up_the_bundle.md before you commit, and check the changelog against your Symfony version, because 2.5.0 dropped Symfony below 6.4 and PHP below 8.3 in a single release. ## FAQ ### What is HWIOAuthBundle used for in a Symfony application? It adds OAuth1.0a and OAuth2 authentication to Symfony as a security authenticator, so login through a third-party provider plugs into the existing firewall and user provider configuration instead of replacing them. It handles the protocol details and ships resource owners for 59 providers. ### Which OAuth providers does HWIOAuthBundle support? The README lists 59, including GitHub, Google, Apple, Facebook, LinkedIn, Slack, Spotify, Twitch, Twitter and Youtube, plus self-hosted and enterprise ones such as Auth0, Azure, Keycloak, Box, Office365 and Amazon Cognito. ### What PHP and Symfony versions does HWIOAuthBundle 2.5 require? Version 2.5.0, published on 2026-02-19, requires PHP 8.3 or newer and Symfony 6.4, 7.4 or 8.0. That release dropped support for PHP below 8.3 and Symfony below 6.4, so both are backward-incompatible changes in one release. ### Does HWIOAuthBundle support OAuth 1.0a as well as OAuth 2? Yes. The README says it adds support for authenticating users via OAuth1.0a or OAuth2, and covers both so that services still speaking the older signed-request scheme can use the same integration surface as OAuth2 services. ### Where are the installation instructions for HWIOAuthBundle? Not in the README, which deliberately delegates setup to docs/1-setting_up_the_bundle.md for the current 2.x line, with the bulk of the documentation in docs/index.md. The bundle is published to Packagist as hwi/oauth-bundle. ## Sources - [hwi/HWIOAuthBundle on GitHub](https://github.com/hwi/HWIOAuthBundle) - [Issues](https://github.com/hwi/HWIOAuthBundle/issues) - [License: MIT](https://github.com/hwi/HWIOAuthBundle/blob/master/LICENSE) - [README](https://github.com/hwi/HWIOAuthBundle/blob/master/README.md) - [Releases](https://github.com/hwi/HWIOAuthBundle/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hwi-hwioauthbundle