Laravel Discourse Sso Laravel Package

Product Decisions This Supports

• Build vs. buy for community forum infrastructure: This package is the "buy/borrow" half of the classic decision — stand up Discourse as the community layer instead of building threaded discussion, moderation, trust levels, and notifications in-house. It removes the one genuinely fiddly piece (Discourse's SSO handshake) from the integration estimate.
• Identity consolidation strategy: It commits you to Laravel as the system of record for users and Discourse as a downstream relying party. That is the strategically correct direction for most B2B products — one login, one user table, one offboarding path — but it is a decision, not a detail, and it forecloses Discourse-native signups, social logins managed in Discourse, and Discourse-side profile ownership.
• Roadmap sequencing for community/self-serve support: If community is on the roadmap, this package makes a "thin launch" credible: forum live in days, no new identity store, no net-new auth surface to secure. It lets you ship community as an experiment rather than a platform program.
• Onboarding and activation design: Because SSO lands users in Discourse already authenticated with mapped custom fields, you can treat forum access as a post-signup activation step rather than a separate registration funnel. This directly informs activation metric definitions and drop-off analysis.
• Support and cost modeling: Fewer credentials means fewer "I can't log into the forum" tickets and no second password-reset flow to staff. That is a real, quantifiable support-cost input to the business case.
• Use cases it unlocks cheaply: Customer community, developer/API support forums, beta feedback boards, documentation discussion, and internal Q&A for staff already in your Laravel app — all gated by your existing auth and roles.

When to Consider This Package

Adopt when all of these are true:

• You have a Laravel application that is already the authoritative identity store, and PHP is a stack your team actively maintains.
• You have chosen Discourse specifically (not Flarum, NodeBB, or a SaaS community product). The package is Discourse-protocol-specific and buys you nothing otherwise.
• You want SSO, not account sync — you are content for Discourse to be read-only as a user source and to have no independent login path.
• The integration scope is genuinely small: login redirect, callback, external ID mapping, a handful of custom fields. That is what this package covers, and it covers it adequately.
• You can accept maintenance ownership. Last release was June 2020; treat this as a code sample you are adopting, not a vendor-supported dependency. Budget a spike to verify compatibility with your Laravel and PHP versions and to pin a Discourse SSO protocol version.
• Your security review tolerates a small, auditable surface: a shared secret, signed payload generation/validation, and an endpoint config. The protocol is documented and the code is short enough to read in an afternoon — that auditability partly offsets the staleness.

Look elsewhere when:

• You need general-purpose SSO (OIDC, SAML, social providers). Use Laravel Socialite, an OIDC client, or a hosted IdP — Discourse supports several of these natively.
• You are not on Laravel, or you are on a Laravel version well beyond what 2020-era package constraints assume and do not want to patch a fork.
• You need active maintenance, security advisories, or vendor support — 46 stars and a four-plus-year-old release means the bus factor is effectively your own team.
• You want bidirectional profile sync, Discourse-side group management, or role provisioning driven from Discourse back into the app. This package is one-directional and will not get you there.
• The forum is the product's primary surface. SSO glue is fine for a secondary community; a primary community deserves a deliberately chosen auth and identity architecture, not a thin bridge.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We can launch a customer community on Discourse without building forum software or creating a second user database. This package is a small, readable connector that lets users who are already logged into our product enter the forum already signed in, with their identity and roles managed in one place. The upside is a credible community launch at a fraction of the cost of a platform program, plus structurally fewer support tickets and no second password surface to secure. The risk is that the connector is a small open-source library with no release since 2020 — so we should treat it as a starting point we own and maintain, not a supported vendor dependency, and budget a short engineering spike to validate compatibility before we commit to a launch date.

For engineering — the ask: Wire it into the existing auth guard, verify the signed-payload flow end to end against our Discourse instance, map external ID plus the custom fields we care about, and pin the dependency. Estimate it as days, not weeks, but own the code: fork it if needed, add test coverage for the callback path, and document the shared-secret rotation procedure.

Framing to avoid: Do not sell this as "Discourse integration is solved." It solves the SSO handshake, which is the tedious part. It does not solve moderation staffing, community seeding, content migration, or the decision of whether a forum is the right bet at all — those remain the actual product risks, and this package should not be used to make them look smaller than they are.