Flarum Sso Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy for community identity. If the roadmap includes a Flarum-based community forum (support, docs, community-led growth), this package is the "buy/adopt" path for SSO rather than a bespoke auth bridge. This release is a maintenance-only patch (3.3.2), so the build-vs-buy calculus is unchanged — but it is the point at which the package can be recorded as a supported dependency rather than an unassessed one.
• SSO rollout and account-linking scope. The one functional fix — setting the username attribute before login in the example flow — is a reminder that attribute mapping (username, email, display name) is a product decision, not an implementation detail. It affects display names, mentions, and profile URLs in the forum, and it is the thing users notice when it is wrong. Budget a short spec for identity attribute mapping before launch.
• Access gating and tiering. SSO determines whether the forum can be tied to paying customers, trial users, or the general public. That decision drives onboarding copy, support macros, and whether forum access is a plan feature — worth settling before the forum is promoted.
• Roadmap sequencing for PHP upgrades. The refactor makes implicitly nullable parameters explicit because they are deprecated in PHP 8.4, and the build tooling now targets PHP 8.3. This package will not be the constraint on your PHP upgrade path — useful when sequencing platform maintenance work.
• Support-cost model. Unified identity reduces duplicate accounts, password-reset tickets, and "I can't log in to the forum" escalations. That is the primary ROI line for the stakeholder case.
• Use cases supported: single sign-on between a Laravel/PHP application and a Flarum forum; consistent identity across product and community; profile/username sync at first login.

When to Consider This Package

Adopt when:

• You run (or plan to run) Flarum and want users authenticated against your existing PHP/Laravel user base rather than managing a second credential store.
• Your team is on PHP 8.3–8.4 — this release explicitly clears PHP 8.4 nullable-parameter deprecations, so it will not block an upgrade.
• You are comfortable with a community-maintained, effectively single-maintainer package and will pin versions, review diffs, and test upgrades in staging.
• Your identity needs are standard SSO with attribute mapping, not enterprise federation.

Look elsewhere when:

• You need SAML, SCIM provisioning, or compliance certifications (SOC 2 evidence, audit trails) — this is not an enterprise identity product.
• You require a vendor SLA or commercial support contract; none is implied here.
• Your IdP is a managed service you would rather integrate against directly, without a PHP-side bridge.
• You cannot absorb single-maintainer risk — in that case, budget for a fork or an in-house implementation.
• Your forum platform is not Flarum; the package is Flarum-specific and does not generalize.

Release read (3.3.2, 10 Oct 2026): patch-level, no breaking changes, no deprecations for consumers, no new features. Contents are one example-flow bug fix, font-path cleanup, a PHP 8.4 forward-compatibility refactor, and CI/docs tooling changes (git-cliff replaces git-chglog; API docs now published from Actions rather than committed). Net signal: healthy maintenance hygiene, not a capability change.

How to Pitch It (Stakeholders)

For executives: This is the SSO bridge that lets our community forum use the same login as the product, so customers get one identity instead of a second account and password. That removes a recurring class of support tickets and makes forum access something we can tie to a plan tier if we choose. Adopting a maintained open-source package is materially cheaper than building and owning an auth bridge, and this release is a small maintenance patch — no migration, no breaking changes, and it clears a PHP 8.4 compatibility issue so it will not hold up our platform upgrades. The main caveat to state plainly: it is community-maintained with essentially one maintainer, so we pin the version and treat upgrades as reviewed changes. Recommended ask is approval to adopt and pin, not a budget line.

For engineering: Upgrade is low-risk and patch-level. Two things to verify rather than assume: (1) the example's username-attribute ordering fix — confirm our attribute mapping sets username before the login call so first-login profiles are correct; (2) PHP 8.4 readiness — the refactor makes nullable params explicit, and the build target is PHP 8.3, so run it through CI on our actual runtime before rolling forward. Docs are now generated from CI into GitHub Pages rather than committed, so update any internal links that pointed at the repo. No public API changes are indicated; pin the version, watch the diff, and stage-test the login flow end to end.