Laravel Config Sso Laravel Package

Product Decisions This Supports

• Security posture is now a first-class decision input. 1.1.0 is not a maintenance release; it closes a pre-account-takeover vector in SSO account linking. PMs should treat the package as touching an authentication-critical surface and factor its security behavior into release planning, not just its admin-UI convenience.
• Account-linking policy must be decided explicitly. SSO sign-in that matches an unverified local account by email now claims that account: password and remember token are rotated and the email is marked verified before sign-in. PMs need to decide whether auto-claiming is the desired product behavior for their user base, or whether some segments (regulated, high-value accounts) require a manual-link or re-verification step instead.
• Credential revocation is opt-in — a decision, not a default. The new UnverifiedAccountClaimed event is the hook to revoke app-specific credentials (2FA, API tokens, passkeys). If no listener is registered, credentials an attacker may have enrolled on the pre-existing unverified account can survive the claim. Building that listener (and deciding what it revokes) is a product-owned security requirement before enabling SSO claiming in production.
• Feature delivery: self-serve SSO configuration, with a stronger safety story. The roadmap case from 1.0.2 still holds — this package supplies the Laravel-side admin settings surface for SSO configuration — but the pitch now includes a defensible answer to "what happens when an SSO identity collides with an existing local account?"
• Roadmap sequencing. 1.0.2 was a UI/DX release; 1.1.0 is a security-behavior release. It still does not signal expanded SSO protocol coverage, SCIM, or enterprise federation breadth. Budget separately for those.
• Migration/hygiene work. forceFill for SSO-created users means email_verified_at is written even when not mass-assignable. PMs should plan a one-time audit of existing SSO-created and unverified local accounts to confirm the new claiming path behaves as intended on real data.
• Use cases. Internal admin SSO settings, B2B SaaS configuration screens, Laravel admin panels already using Livewire/Flux, and demo/workbench environments — now with a clearer (but still partial) answer on account-collision handling.

When to Consider This Package

• Consider it when the product is a Laravel application, the team is comfortable with Livewire and Flux UI, and the near-term need is an admin-configurable SSO settings experience rather than a fully custom identity platform.
• Consider it when time-to-market matters and the alternative is building SSO configuration CRUD, admin routing, validation, and UI plumbing in-house.
• Consider it when the team is willing to own the surrounding policy: define account-linking rules, implement an UnverifiedAccountClaimed listener that revokes 2FA/API tokens/passkeys, and audit existing unverified local accounts before enabling SSO.
• Consider it more favorably than in 1.0.2 for pilot programs, since the package now addresses a known account-takeover pattern rather than deferring it entirely to the integrating app.
• Look elsewhere when the requirement is enterprise-grade SSO across multiple protocols with formal SLAs, security certifications, SCIM provisioning, advanced audit controls, or a mature long-term support commitment.
• Look elsewhere if the team cannot adopt Flux/Heroicons conventions, does not use Livewire, or wants to avoid a UI dependency in a security-sensitive admin surface.
• Look elsewhere if the product needs a documented, independently reviewed authentication threat model, or if the auto-claim-on-unverified-email behavior conflicts with compliance obligations (e.g. mandated re-verification or account-linking consent flows).
• Look elsewhere if the team cannot staff the opt-in credential-revocation listener; without it the security fix is only partial.

How to Pitch It (Stakeholders)

• For executives: Release 1.1.0 upgrades this package from a UI convenience to a security-relevant dependency. It fixes a real account-takeover pattern where an attacker pre-registers an unverified local account using a victim's email before that victim signs in via SSO; the package now claims the account, rotates credentials, and marks the email verified. It also emits an event so our app can revoke 2FA, API tokens, and passkeys. There are no breaking API changes, but there is a behavior change in how SSO sign-ins interact with existing unverified accounts, and the revocation step is opt-in — meaning we must build it. Recommend we adopt the upgrade promptly, budget a small amount of engineering for the listener and an account audit, and continue to treat protocol breadth, SLAs, and certifications as outside this package's scope.
• For engineering: 1.1.0 rotates password and remember token and force-sets email_verified_at on SSO sign-in matching an unverified local account, and emits CleaniqueCoders\ConfigSso\Events\UnverifiedAccountClaimed. SSO-created users now use forceFill, so email_verified_at is persisted even when guarded. Action items: register a listener that revokes 2FA, API tokens, and passkeys (and decide whether to notify the user or force a re-auth); audit existing records where an unverified local account shares an email with an SSO identity; verify no downstream logic assumed unverified accounts would never be auto-claimed or that email_verified_at could only be set via mass assignment; and re-confirm Flux licensing and protocol/security requirements, since the package still does not provide SCIM, multi-protocol federation, or certification evidence.