Product Decisions This Supports
- Build vs. buy for admin-panel authentication. If your product surface is a Filament admin panel and your organization standardizes on TDC as an identity provider, this package replaces a bespoke SSO integration (OAuth/SAML handshake, user provisioning, callback handling, session mapping) with a maintained dependency. The decision it informs is: do we staff a 2–4 week auth integration, or adopt a 0.x package and accept its maturity risk?
- Roadmap sequencing for "enterprise readiness." SSO is typically a gating requirement for enterprise/agency deals and for internal compliance review. A package like this can pull SSO forward on the roadmap without consuming a full sprint of engineering capacity — useful when SSO is a checkbox blocking a launch rather than a differentiator.
- Use cases it unlocks: internal back-office and ops tooling behind corporate identity, agency/government deployments where an IdP is mandated, multi-tenant admin panels where per-tenant IdP configuration is required, and replacing shared-password admin access ahead of a security audit.
- Scope boundary decision. Because it is Filament-specific rather than a general Laravel guard, it constrains the decision to Filament-based surfaces. If you also run customer-facing auth or API token issuance, you still need a separate answer — this package does not make SSO a solved problem across the whole product.
- What it does not currently support: the 0.1 release notes contain only a changelog link with no described functionality, so there is no confirmed feature set to plan against — no stated support for provisioning/SCIM, role or group mapping, multi-IdP routing, logout propagation, or token refresh. Treat all of those as unvalidated until the source and README are reviewed.
When to Consider This Package
Adopt when all of the following hold:
- Your admin surface is built on Filament (version compatibility is unconfirmed — verify against your pinned Filament major before committing).
- TDC is your actual or contractually required IdP. "TDC SSO" is provider-specific; if you are on Okta, Entra ID, Auth0, or Google Workspace, this is likely the wrong package regardless of quality.
- You can tolerate a 0.x dependency: expect breaking changes between minor versions, unpinned API surface, thin documentation, and a bus factor of one maintainer until proven otherwise.
- The integration is non-critical-path: an internal admin panel where a day of auth downtime is an inconvenience, not a revenue event.
Look elsewhere when:
- You need a general-purpose Laravel SSO/SAML/OIDC solution — prefer Socialite providers, Laravel Fortify plus a maintained OIDC library, or a commercial IdP-bundled SDK.
- You require enterprise support, an SLA, or a security review trail (SOC 2, pen-test reports, CVE response process). A 0.1 release will not survive procurement.
- You need SCIM provisioning, fine-grained group-to-role mapping, or multi-IdP tenancy — no evidence any of this exists yet.
- Your team cannot read and own the integration code if the maintainer goes quiet. With a single 0.1 tag and no release notes, the realistic mitigation is vendoring or forking.
Diligence required before adoption: inspect the repository for test coverage, CI, license, dependency constraints, and last-commit activity; confirm whether it wraps an existing well-maintained OIDC client or hand-rolls the protocol (hand-rolled SSO is a security liability); and check whether the 0.1 tag is a functional release or a namespace-squat placeholder.
How to Pitch It (Stakeholders)
For executives: This is a small, single-purpose integration that lets our Filament admin panels authenticate through TDC's identity provider instead of local passwords. It removes a common enterprise and compliance blocker — "do you support SSO?" — at a fraction of the cost of building it ourselves. The trade-off is maturity: it is at version 0.1, from a single maintainer, with no published feature documentation. I recommend we treat it as a time-boxed evaluation, not a commitment: a one-to-two day spike against a non-production admin panel, with a clear fallback to a standard OIDC library if it does not hold up. We should not put it on a customer-facing or revenue-critical path until it reaches 1.0 or we have vendored it internally.
For engineering: Evaluate as a thin Filament auth adapter for TDC. Two questions decide it: (1) does it delegate the protocol to a maintained OIDC/SAML client, or implement it in-house? (2) does its user-mapping model fit our users table and role structure without forking? Pin the exact version, wrap the integration behind our own interface so it can be swapped, and confirm Filament major-version compatibility before writing any code against it. Absent a credible answer on (1), default to building on a standard library — the integration is small enough that owning it is cheaper than inheriting an unmaintained auth path.