- Is artdarek/oauth-4-laravel compatible with Laravel 5, 6, or later?
- No. The package's Composer constraint pins illuminate/support to the 4.x line and it relies on Laravel 4 conventions such as provider and alias registration in app/config/app.php, Config::get and App::make. Adopting it in Laravel 5 through 12 is not a configuration change but a rewrite. Treat it as a reference implementation to be replaced rather than a dependency to install.
- How do I install and configure artdarek/oauth-4-laravel in a Laravel 4 app?
- Run composer require artdarek/oauth-4-laravel inside a Laravel 4.0 to 4.2 application, then register the service provider and the OAuth alias in app/config/app.php. Publish the config with php artisan config:publish artdarek/oauth-4-laravel and add your client id, secret and redirect URI there. Because the config file is published into your app, in-place edits are a common source of staging versus production drift, so keep it under version control.
- Which OAuth providers and OAuth versions does artdarek/oauth-4-laravel support?
- It is a thin wrapper around the lusitanian/oauth (oauth-php) library, so coverage is whatever that library implements: OAuth 1.0a plus partial, dated OAuth 2.0, commonly used for providers such as Facebook, Google, Twitter and GitHub. There is no PKCE, no current redirect-URI validation guidance and no modern token-rotation support. Several major identity providers have retired the OAuth 1.0a endpoints this library targets, so a working integration can break without any change on your side.
- Is artdarek/oauth-4-laravel still maintained and safe to use in production?
- No. Both the package and the underlying oauth-php library are unmaintained, with no security response path and no CVE feed; the star count reflects historical Laravel 4 adoption, not current viability. Running it in production means accepting unpatched risk and PHP-version fragility. It is only defensible in a frozen legacy application that is isolated from your upgrade path.
- What should I use instead of artdarek/oauth-4-laravel for social logins?
- For consuming OAuth, use laravel/socialite, the first-party and actively maintained option, or league/oauth2-client for non-social OAuth 2.0 providers; both support PKCE. If you are issuing OAuth rather than consuming it, use laravel/passport for a full OAuth 2.0 authorization server, laravel/sanctum if you only need first-party API tokens, or league/oauth2-server wrapped in your own service provider for niche flows.
- How do I authenticate a user with the OAuth facade in artdarek/oauth-4-laravel?
- Resolve a consumer through the facade, for example OAuth::consumer('Facebook'), redirect the user to the authorization URI it returns, then handle the callback with OAuth::finish() and exchange the code via OAuth::getAccessToken(). You then persist the token yourself and attach it to subsequent API calls. Because all protocol logic lives upstream, the facade is a thin proxy and debugging quickly drops into the oauth-php library.
- Does artdarek/oauth-4-laravel support PKCE and modern OAuth 2.0 security practices?
- No. The library predates PKCE, current redirect-URI validation guidance and modern token-rotation expectations, so the flows it implements are dated by design. If your security review or a provider's current requirements call for PKCE, this package cannot satisfy them. That alone usually disqualifies it for any new work.
- Will artdarek/oauth-4-laravel work on PHP 7 or PHP 8?
- Treat that as a risk, not a supported path. The code is PHP 5-era and exposed to PHP 7 and 8 deprecations and fatals such as dynamic properties, removed functions and signature or typing changes. Upgrading the runtime underneath an app that still depends on this package is a latent outage, so pin the PHP version and test the upgrade in isolation first.
- Where are access tokens stored when using artdarek/oauth-4-laravel?
- The package does not give you a managed token store. Protocol and signature handling live in oauth-php, which keeps tokens in memory or session during the flow, and it is your application's job to persist access and refresh tokens in your own database schema. Audit that schema before any migration, because it may hold production data referenced elsewhere in the codebase.
- How do I migrate off artdarek/oauth-4-laravel in a legacy Laravel 4 app?
- Inventory every OAuth:: call and config reference, vendor the package into the repository, pin the PHP runtime, and hide all calls behind an internal AuthClient interface so the eventual swap is a single-class change. Then replace the implementation with laravel/socialite or league/oauth2-client for consuming OAuth, or laravel/passport and laravel/sanctum when you are issuing tokens. That sequencing keeps the legacy app running while removing the abandoned dependency from your critical path.