- How do I install the Filament SSO Client plugin in a Laravel application?
- Install it with Composer using jeffersongoncalves/filament-sso-client, which also pulls in the upstream jeffersongoncalves/laravel-sso-client package. Register the plugin in the relevant Filament PanelProvider, then publish the configuration file so you can supply your identity provider settings. The plugin itself is a thin adapter, so all IdP metadata, entity ID, ACS/logout URLs, and signing certificates are configured through the upstream client's published config.
- Does this plugin support SAML 2.0, OIDC, or both?
- The plugin's release notes refer generically to SSO without naming SAML 2.0 versus OIDC, while the actual protocol handshakes and token validation live in the upstream laravel-sso-client package. Because the protocol choice changes IdP registration, testing, and failure analysis significantly, confirm it against the upstream package documentation before committing. The overview mentions OAuth/OpenID Connect providers such as Google and GitHub, but you should verify enterprise SAML support directly rather than assume it.
- Which PHP, Laravel, and Filament versions does this package support?
- It is built as a Filament v3 panel plugin and targets Laravel 10/11 applications on PHP 8.1 or newer. A Filament v4 upgrade path is not stated in the available documentation, so check the composer.json constraints if your project is already on v4. Since this is a 1.0.0 release, treat the version matrix as something to re-verify on each update.
- Can I keep normal password login enabled alongside SSO?
- Yes. The plugin hooks into Filament's login page and supports three modes: an SSO button shown alongside the standard form, SSO-only mode, and forced redirect to the identity provider. Adopting the button mode first is the least invasive way to roll it out. Keeping local authentication available is also the simplest break-glass safeguard while you validate the IdP integration.
- Will SSO-only or forced redirect lock me out of my admin panel?
- It can. SSO-only and forced-redirect modes are single configuration flips with a large blast radius, and administrators can be stranded if the IdP, certificates, or metadata drift. A documented break-glass local admin path is mandatory before you enable either mode in production. The plugin does not ship an explicit lockout-recovery mechanism, so plan that operationally.
- How are users created or linked to existing accounts on first SSO login?
- The package advertises automatic user creation and account linking, which means a user record is provisioned or matched when someone authenticates through the identity provider. What is not documented is just-in-time provisioning detail, attribute-to-column mapping, or role and group mapping from IdP claims. If your rollout requires role mapping or MFA policy passthrough, verify the behaviour against the upstream client before relying on it.
- Does the single logout middleware add a remote call to every panel request?
- The plugin enforces Single Logout through middleware on panel requests, which implies some session or back-channel state check on each request. The documentation does not state whether that lookup is cache-backed and local or a remote call to the identity provider. Confirm this and measure the overhead before deploying to a high-traffic panel, since a per-request network hop would be a serious performance concern.
- Can it handle multiple identity providers or per-tenant SSO?
- Out of the box it wraps a single upstream client configuration, so it is designed for one workforce IdP per panel or application. It is not positioned for per-tenant IdPs in a multi-tenant SaaS admin panel or for consumer-facing B2C login without extension work. For multi-IdP scenarios you would need to build your own provider resolution on top of the upstream package.
- Is this package production-ready and actively maintained?
- It is a 1.0.0 first release with no public production track record, and the upstream client it depends on is itself at a young 1.1+ version. Both packages appear to be maintained by the same individual, so bus factor and support depth are the main risks to evaluate. Expect API churn in pre-1.0 upstream changes and treat vendor continuity as an explicit assumption you have validated.
- What configuration is needed to connect Google, GitHub, or an enterprise IdP?
- Publish the package config and fill in the upstream client's identity provider settings: metadata, entity ID or client credentials, ACS and logout URLs, and signing certificates where applicable. On the IdP side you must register the service provider and allow-list the callback and logout URLs, which usually takes more time than the code changes. Attribute and claim agreements should be settled at the same time so user provisioning works on first login.