Filament Oauth2 Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel SSO: OAuth2/OIDC login for Filament panels is security-sensitive, low-differentiation plumbing. A package like this turns a multi-day integration (provider registration, callback handling, user mapping, token refresh, error states) into configuration — a clear "buy/borrow" call over custom Socialite wiring.
• Feature bet: enterprise/team tier readiness. "Log in with Google Workspace / Microsoft Entra / GitHub" is a recurring procurement checkbox for B2B and internal-tool customers. This package is a cheap way to close that gap without committing roadmap capacity.
• Roadmap sequencing: if SSO is a blocker on a deal or an internal security review, this is a short-cycle unblock (days, not a quarter) and can be slotted ahead of larger auth work (SAML, SCIM, RBAC).
• Use-case fit: internal back-office and ops panels, agency/client Filament builds where each deploy needs admin access control, and B2B SaaS admin surfaces where the customer's IdP is the source of truth for who gets in.
• Scope boundary decision: using this keeps your auth investment confined to authentication for the admin panel — it does not solve authorization, provisioning/deprovisioning, or per-tenant IdP routing. Decide explicitly whether those are in scope before adopting.

When to Consider This Package

Consider it when:

• You run one or more Filament panels and want SSO/social login as a configuration task, not a build.
• Your IdP needs are standard OIDC/OAuth2 (Google, Microsoft, GitHub, generic provider) and you don't need SAML or SCIM.
• Your admin user base is small and internal or semi-trusted, and you're comfortable that access revocation depends on your IdP plus your own user-enable/disable controls.
• You can pin a version and absorb an upgrade weekend — the jump from v1.1.0 to v2.1.0 implies a breaking v2.0.0, so treat it as a migration, not a patch.

Look elsewhere (or build) when:

• You need SAML 2.0, SCIM provisioning, per-tenant IdP routing for multi-tenant SaaS, or step-up/MFA policy enforcement inside the panel.
• The release notes are this thin. A changelog consisting of a compare link and nothing else is a maintainer-signal risk: you can't assess what broke, and your team will be reading diffs to plan the upgrade. Verify Filament major-version compatibility and commit history before betting a customer commitment on it.
• Bus factor matters to you: single-maintainer packages in the authentication path deserve a fork-and-vendor contingency or a documented exit plan (drop back to raw Socialite + a small custom Filament auth guard).

How to Pitch It (Stakeholders)

To executives: This is a low-cost way to check the "SSO / enterprise identity" box on customer security reviews and internal audits. It replaces custom login plumbing in our admin panel with a maintained dependency, so the cost is an integration and an upgrade, not a build. The trade-off is dependency risk: it's a small, single-maintainer package sitting in an authentication path, so we pin the version, review the v2 breaking changes before upgrading, and keep a fallback plan to own the Socialite integration ourselves if maintenance lapses.

To engineering: Filament-native OAuth2/OIDC login — provider config plus user mapping, instead of hand-rolling callbacks and token handling. Two things to confirm before we commit: (1) which Filament major version v2.x targets, and (2) what actually changed in v2.0.0 — the v2.1.0 notes are only a diff link, so budget a diff review rather than assuming a clean upgrade from v1.1.0. Keep authorization and user lifecycle in our own code so we aren't dependent on the package for access revocation.