Oauth2 Client Laravel Package

Product Decisions This Supports

• Feature bets: Enables “Sign in with [Provider]” and “Connect your [Provider] account” experiences for Google, GitHub, Microsoft, Slack, Salesforce, and similar OAuth 2.0 providers. The package supplies the authorization-code plumbing; provider-specific clients handle vendor quirks.
• Roadmap prioritization: Makes third-party integrations easier to scope as low-to-medium effort when a provider client already exists, rather than multi-sprint bespoke OAuth work. It supports authorization-code flow, PKCE, refresh tokens, access-token retrieval, and resource-owner lookup.
• Build vs buy: Strong case for buy/use the OSS library. OAuth is security-sensitive and standards-driven; building RFC 6749 handling in-house is hard to justify. The MIT license, established release history, and provider ecosystem reduce procurement and delivery risk.
• Use cases: Social login, account linking, third-party API authorization, background sync via refresh tokens, marketplace/partner app authorization, and internal tools that need to call OAuth2-protected APIs.
• Product boundary: It is an OAuth2 client base, not a complete identity product. It does not provide login UI, user accounts, session management, token storage, consent UX, account linking, revocation flows, or Laravel integration. Those remain product and engineering scope.
• Laravel-specific decision: For common social login, Laravel Socialite is usually the faster product path. Choose league/oauth2-client when you need a provider Socialite does not cover, deeper control over the OAuth flow, or a provider-agnostic base for multiple integrations.

When to Consider This Package

Consider it when:

• You need standards-compliant OAuth 2.0 authorization-code flow, ideally with PKCE, in a PHP or Laravel application.
• You must integrate with a provider that has an official or third-party league/oauth2-* client, or you are prepared to build and maintain a small provider client.
• You need refresh-token support for long-lived integrations or direct access to token and resource-owner data.
• You want a mature, MIT-licensed OAuth base instead of a bespoke implementation.
• Your team can own the surrounding product concerns: secure token storage, state validation, consent/error handling, account linking, token revocation, and customer support.

Look elsewhere when:

• The only need is “Log in with Google/GitHub/Facebook” in Laravel: use Laravel Socialite first.
• You need enterprise SSO, SAML, OIDC identity management, user directories, MFA, or full authentication: use a dedicated identity provider or enterprise auth platform.
• You need OAuth 1.0, a full authorization server, or a managed drop-in login service.
• You cannot invest in secure token storage and OAuth operational handling; a managed integration may be safer.
• You need a Laravel-native, batteries-included package with routes, UI, and user mapping out of the box.

How to Pitch It (Stakeholders)

Executive summary: league/oauth2-client is a mature, MIT-licensed OAuth 2.0 client base that lets us add third-party sign-in and account-connection features without building security-sensitive protocol code ourselves. It is not a turnkey login product and is not Laravel-specific. The recommendation is to use it selectively: Laravel Socialite for common social login, and league/oauth2-client plus provider clients for custom or less-common OAuth2 integrations.

Engineering summary: The package is PSR-compliant, supports PHP 7.1 through 8.5, and covers authorization-code flow, PKCE, refresh tokens, access tokens, and resource-owner retrieval. We still own state/CSRF validation, token persistence and encryption, provider-client selection, consent UX, error handling, and account linking. Start with one provider pilot, define token-storage and security requirements, and budget for provider-specific edge cases. This lowers integration risk and time-to-market versus custom OAuth, while avoiding over-reliance on a package that is not a full identity solution.