- How do I install lusitanian/oauth with Composer?
- Run composer require lusitanian/oauth in a PHP project that meets the library's older dependency constraints. The package is framework-agnostic, so installation does not register a Laravel service provider or publish config. You then instantiate provider service classes, pass client credentials, and handle token persistence in your application code.
- Does lusitanian/oauth work with Laravel 10 or Laravel 11?
- There is no official Laravel integration in the library, so it does not ship a service provider or facade for current Laravel versions. It can only work as a plain PHP dependency if its 2018-era Composer constraints resolve against your Laravel stack. In practice, Guzzle and PHP version conflicts are likely, so treat Laravel 10 and 11 support as unverified and test in a spike first.
- Is lusitanian/oauth a good alternative to Laravel Socialite?
- Usually no. Laravel Socialite is first-party, maintained, and covers OAuth 2 providers such as Google, GitHub, and Microsoft, which is the common Laravel login use case. Lusitanian OAuth is only worth considering when you specifically need OAuth 1.0a request signing for a legacy provider that Socialite does not support.
- Does lusitanian/oauth support OAuth 1.0a?
- Yes, it provides OAuth 1.0a client support alongside OAuth 2.0, including request signing through its service classes. That OAuth 1 capability is the main reason to evaluate it today, because Socialite is OAuth 2 only. However, verify each provider's current endpoints, since some 2018-era implementations may be stale.
- Does lusitanian/oauth support PKCE or OpenID Connect?
- No. The library predates OAuth 2.1 and does not provide PKCE, OpenID Connect, id_token parsing, JWKS validation, or nonce handling. That makes it unsuitable for SPAs, mobile apps, native clients, or any flow where you need verified identity rather than just an access token.
- How do I store and refresh OAuth tokens with lusitanian/oauth?
- The library returns token objects such as StdOAuth2Token, and it offers a pluggable token storage concept, but your application must persist, encrypt, and refresh those tokens. It does not schedule refreshes or manage token lifecycle for you. In Laravel, that usually means your own database columns, encryption, and a refresh job or service.
- Is lusitanian/oauth still maintained?
- Effectively no. The last release was in April 2018, and the project has no active upstream security patching for modern OAuth requirements. Because OAuth clients are security-sensitive, using it means accepting that you may need to fork and maintain it internally. Any production use should include contract tests against provider sandboxes and a plan for internal patching.
- Why does lusitanian/oauth conflict with Guzzle 7 in Laravel?
- The library's HTTP layer pins older Guzzle ranges, while current Laravel applications commonly require guzzlehttp/guzzle ^7. Composer can then fail to resolve a compatible dependency set, often during an upgrade. Check composer why-not guzzlehttp/guzzle and be prepared to fork or avoid the package if constraints cannot be relaxed.
- How do I add a custom OAuth provider or configure scopes and callback URLs?
- You typically extend the library's abstract service or provider service classes and supply client ID, client secret, scopes, and redirect URI in your own configuration. The package does not publish Laravel config or register bindings, so you write the wrapper service and service provider yourself. Confirm the provider's current OAuth endpoints before implementing the adapter.
- Should I use league/oauth1-client or league/oauth2-client instead?
- For OAuth 1.0a, league/oauth1-client is the maintained alternative to evaluate first. For OAuth 2 in Laravel, use Laravel Socialite or league/oauth2-client rather than this library, especially if you need PKCE or OpenID Connect. Lusitanian OAuth should be a fallback only when a specific legacy provider forces OAuth 1 and no maintained client fits.