Wn Sso Plugin Laravel Package

Product Decisions This Supports

• Admin-plane security posture. This is not a customer-facing feature; it is an internal access-control decision for the CMS backend. It moves admin authentication from locally-managed passwords to an existing identity provider (Google Workspace, Microsoft Entra ID, Okta, GitHub, etc.) via Laravel Socialite drivers.
• Enterprise/procurement readiness. "Do you support SSO on your admin console?" is a recurring line item in security questionnaires, SOC 2 / ISO 27001 vendor reviews, and enterprise onboarding. This package is a cheap way to answer yes without building OAuth flows in-house.
• Build vs. buy (build vs. configure). Building OAuth + callback handling + user provisioning + token refresh is roughly one to three weeks of engineering plus permanent maintenance. Adopting a plugin trades that for configuration plus a dependency-risk assessment. For a Winter CMS deployment, this is clearly the "configure" side of the decision.
• Lifecycle automation of admin access. Centralizing identity means joiner/mover/leaver for CMS admins is handled by the IdP: revoke in the directory, lose CMS access. That is a process win (offboarding latency drops from "whenever someone remembers" to minutes) more than a technical one.
• Roadmap scoping. Supports deferring adjacent investments: MFA, password policy, session expiry, and brute-force protection all become IdP responsibilities rather than CMS backlog items. It also clarifies what is not solved — role/group mapping, SCIM provisioning, and audit logging may still be roadmap items.
• Deployment patterns. Most valuable for agency/multi-client Winter deployments (many admin users, high turnover, client-handover requirements) and for internal platform teams running Winter as a back-office tool. Low value for single-admin, self-hosted hobby sites.
• Risk acceptance decision. With 8 stars, 0 dependents, and a single-package maintainer footprint, adopting this is explicitly accepting single-maintainer risk in exchange for near-zero license cost (MIT). That trade-off should be recorded, not assumed.

When to Consider This Package

Consider it when:

• You run Winter CMS and the backend admin user base is ≥5 people, or turns over regularly (contractors, agency clients, rotating ops staff).
• Your organization already has a central IdP and a policy — formal or cultural — that admin access must go through it.
• You need SSO to satisfy a customer security review, a compliance audit, or an internal access-control standard, and a full IAM integration is disproportionate.
• You want OAuth login without owning OAuth code: Socialite is a well-understood Laravel primitive, so the maintenance surface is thin and diagnosable.
• You can absorb the dependency yourself if needed — i.e., you have PHP/Laravel capability and are willing to pin a version or fork.

Look elsewhere (or build) when:

• You need SAML 2.0. Socialite is OAuth/OIDC-oriented; SAML-only IdPs are out of scope. This alone disqualifies it for many enterprises.
• You need automated provisioning/deprovisioning (SCIM), group-to-role mapping, or IdP-driven permission sync. Verify exactly what the plugin does with the returned identity before assuming any of this exists; if it only authenticates and links users, those remain your build items.
• You are not on Winter CMS. October CMS v3, plain Laravel, or Filament apps should implement Socialite directly — the plugin's value is its Winter backend integration (login flow, user binding, settings UI), which does not transfer.
• You require vendor support, an SLA, or a maintained security-response commitment. 8 stars and 0 dependents means no ecosystem pressure; you are effectively the maintainer of last resort. If a security patch cannot wait on a volunteer, budget for a fork.
• You need multi-tenant per-customer IdP routing (each client authenticates against their own tenant). Confirm this is supported; a single-provider configuration is the common default and would force a custom build.
• Local-password fallback and break-glass access are not addressed. If the plugin cannot coexist with a local admin account, an IdP outage becomes a full backend lockout. That is a blocker for production until proven otherwise.

How to Pitch It (Stakeholders)

For executives (30 seconds):

Our CMS admin login is currently a set of local passwords we manage by hand. This plugin lets our administrators sign in with the same corporate account they already use — the one with MFA and the one IT already disables the day someone leaves. It is MIT-licensed, so the cost is configuration time, not procurement. The business outcome is a cleaner security answer in enterprise deals and vendor reviews, and faster, more reliable revocation of access when staff or contractors change. The trade-off is that it is a small open-source project, so we treat it as code we may need to maintain ourselves rather than a supported product.

For engineering (the real message):

• Scope is narrow and familiar: it wires Laravel Socialite into Winter's backend auth, so the OAuth surface is standard and reviewable in an afternoon.
• We configure providers, not code. Secrets live in env/config, never in the repo.
• Two things must be verified before we commit: (1) that a local/break-glass admin path still works if the IdP is unreachable, and (2) what the plugin actually does at first login — auto-create users vs. bind to existing backend accounts — because that determines whether unauthorized accounts can be self-provisioned.
• Dependency posture: pin the version, review the release diff on upgrade, and assume we fork if upstream goes quiet. It is a few hundred lines of integration, not a platform.
• Out of scope unless we build it: group-to-role mapping, SCIM, and audit log export. If we need those, they go on the roadmap as our work, not the plugin's.

Decision requested: approve piloting on staging with our primary IdP, with a documented fallback-admin procedure, and revisit once we have confirmed the first-login and lockout behavior.