Weave Code
Laravel Discourse Sso Laravel Package
spinen/laravel-discourse-sso
Provides single sign-on between a Laravel application and a Discourse forum using Discourse's SSO protocol. It builds signed payloads, validates nonces, and lets users log in to Discourse with their existing Laravel credentials, keeping account data in sync and avoiding separate forum passwords.
Integrate Discourse SSO into Laravel
Frequently asked questions about Laravel Discourse Sso
- What does spinen/laravel-discourse-sso actually do?
- It is a narrow protocol adapter that implements Discourse's SSO contract between a Laravel app and a Discourse forum. Laravel stays the identity source, Discourse acts as the relying party, and the package builds the signed payload, redirects the user, validates the callback, and maps user attributes. Users log in to Discourse with their existing Laravel credentials, so there is no separate forum password to manage.
- How do I install and configure spinen/laravel-discourse-sso in Laravel?
- Install it with Composer as spinen/laravel-discourse-sso, then publish its configuration and set the shared SSO secret that Discourse generated for your forum. You expose the SSO initiation and callback routes and enable the Discourse SSO setting pointing at your Laravel endpoint. Use a non-production secret and a staging Discourse instance first, because the package stores security-sensitive configuration that must not be shared across environments.
- Which Laravel and PHP versions does this package support?
- The last release was in 2020, so it most likely targets older Laravel and PHP versions and will not run unmodified on the current stack. Treat the PHP/Laravel support matrix as unknown until you verify it, including OpenSSL availability and whether it uses deprecated framework APIs, facades, or helpers. Run a short compatibility spike before committing, and be prepared to fork or reimplement.
- Is spinen/laravel-discourse-sso still maintained?
- Signals are weak: the last release was 2020 and the repository has low stars, so you should assume limited or no ongoing maintenance. That matters because this is security-sensitive code handling HMAC secrets and signature validation. Do not adopt it as an unmaintained transitive dependency without an explicit ownership decision, and pin whichever version or fork you choose.
- How does the Discourse SSO handshake work with Laravel as the identity provider?
- Discourse redirects the user to your Laravel SSO endpoint with a signed payload containing a nonce and a return_sso_url. Laravel authenticates the user, builds a response payload with user attributes, signs it with the shared HMAC secret, and redirects back to the return URL. Discourse validates the signature and nonce, then creates or updates the local user and logs them in.
- Is this package secure enough for production use?
- It can be, but only after a security review, because the risk surface is real: HMAC secret handling, constant-time signature comparison, nonce and replay protection, URL and base64 encoding, and open-redirect behavior around return_sso_url. Test the invalid-signature, tampered-payload, and replayed-nonce paths explicitly rather than trusting the package's test coverage, which is unclear. Put the package behind an internal adapter so you can patch or replace it without touching domain code.
- What happens when a user changes their email or username in Laravel?
- User-attribute drift is a real concern with this package, since Discourse may key accounts on email or external ID. Plan for email changes, username collisions, and duplicate-account behavior before go-live, and decide whether Discourse should update on next SSO login or be corrected explicitly. External ID mapping should be confirmed, because falling back to email as the identifier makes later changes painful.
- Does it support logout, deprovisioning, groups, or admin roles?
- You should assume login only. Logout, deprovisioning, account disabling, group/role sync, and Discourse admin or moderator mapping are not safe assumptions with a package of this scope. If you need group-based access in Discourse, verify whether custom fields or group attributes are supported, and design deprovisioning as a separate concern rather than expecting the SSO bridge to handle it.
- How should I test the Discourse SSO integration before rolling it out?
- Start with a staging Discourse instance and a non-production shared secret, then exercise each path individually: new-user creation, existing-user login, email change, username conflict, disabled user, and invalid signature. Run the flow behind a feature flag and monitor login failures during a pilot group rollout. A short technical spike against your target Laravel and PHP versions should come first, since compatibility is the biggest unknown.
- What if the package does not work on current Laravel - can I fork it or write it myself?
- Yes, and that is often the right answer here, because the Discourse SSO protocol has a small surface area: sign a payload, validate the callback, check the nonce, map attributes, redirect. Fork the package into an internal repository, patch compatibility, add tests for signature validation and callback handling, and pin the fork. Alternatively implement a minimal internal SSO service and skip the dependency entirely, which gives you clear ownership of this security-sensitive code.
Weaver
How can I help you explore Laravel packages today?