Single sign-on across a forum and a main site

The situation is common enough to be a category. There is a main site with accounts — customers, members, subscribers, staff — and a community platform is being added beside it. The community can either issue its own accounts or accept the ones that already exist.

Issuing its own is simpler for exactly one afternoon and expensive for the rest of the installation's life: two password resets, two profiles that drift, and a moderation problem where banning somebody in one system leaves them fully functional in the other. Sharing is more setup and fewer permanent problems.

Decide which system owns the person

Before any protocol, one decision settles most of the rest: which system is authoritative for identity. Almost always it is the main site, because that is where the commercial or organisational relationship lives. The forum becomes a consumer of identity rather than a source of it.

The consequence is worth stating plainly, because it surprises people later. If the main site owns identity, the forum should not offer registration, password reset or email changes at all. Leaving those routes enabled produces accounts that exist only in the forum, which is precisely the duplication the exercise was meant to prevent, and the ones that appear are always discovered at an inconvenient moment.

The three mechanisms

A shared session is the crude option and occasionally the right one. Both applications sit on the same domain, read the same cookie, and validate it against the same store. It requires the two to be genuinely co-located and to agree on a session format, which in practice means the forum has to be modified. Fast, fragile, and hard to hand over.

OAuth 2.0 with OpenID Connect is the mainstream answer. The main site — or a dedicated identity provider in front of it — issues tokens; the forum redirects an unknown visitor there, receives them back with a token, and reads the identity from it. Every platform discussed on this site either supports it in core or has a maintained extension for it. If there is no strong reason to do otherwise, this is the choice.

SAML is the enterprise variant, and it exists in this list because if the organisation already runs a directory that speaks SAML, arguing for something else is a losing argument. It is more configuration and more XML, and it works.

What each platform expects

Support varies in kind, not only in presence. Discourse's implementation is unusually complete: it can be configured so that the forum has no local accounts whatsoever, which enforces the single-owner rule rather than relying on discipline. NodeBB, Vanilla, Mattermost and Zulip all have well-trodden paths and reasonable documentation.

The traditional PHP boards can all be made to work, generally through an extension and some patience. What to check before committing is not whether an extension exists but when it was last updated against the platform's current release — an authentication extension that stops being maintained is not a feature that degrades, it is a locked front door.

Flarum's small-core design means authentication is an extension by construction, which is consistent and means the same maintenance question applies with more force.

Matching an existing member to an existing account

If the forum already has members, the two sets have to be reconciled, and this is where most of the actual work is.

Email address is the obvious join key and it is riskier than it looks. Addresses get reused within families and small organisations, people change them, and a match on a stale address hands one person's account to another. Where the stakes are meaningful, the safer pattern is to link accounts on first login: the member signs in with the main site's credentials, is shown which forum account is about to be attached, and confirms it.

Whatever the mechanism, store the identity provider's stable subject identifier alongside the forum account rather than relying on the email match every time. Email is a contact detail; the subject identifier is the identity.

Groups and permissions, which are a second problem

Authentication answers who somebody is. It says nothing about what they may do, and the two get conflated constantly. A subscriber tier on the main site does not become a forum permission group by itself.

The mechanism is claims: the identity provider includes group membership in the token, and the forum maps those claims onto its own groups. Most implementations support this and few projects configure it, which is how you end up with an SSO integration that logs paying members in and then shows them the same board as everyone else.

Map as few groups as the requirement genuinely needs. Every mapped group is a rule that has to stay correct on both sides through future reorganisations, and a stale mapping fails in the expensive direction — granting access rather than withholding it.

What this does to email

A forum sends notifications, and once identity is shared the question of which system holds the address becomes load-bearing. If the main site is authoritative, the forum should read the address from the token and never let a member edit it locally, or the two will diverge and notifications will go to an address nobody reads.

There is also a deliverability consequence worth planning for. Two systems now send mail on behalf of the same organisation, frequently from two different providers. Both need to be authorised to send for the domain, and a community launch is exactly the moment a large volume of unfamiliar mail leaves an unfamiliar sender — which is how a launch ends up in spam folders on day one.

Logout is harder than login

Login is a redirect and a token. Logout is a distributed systems problem, and it is the part that gets skipped.

Signing out of the main site does not sign the visitor out of the forum unless something makes it happen, so a person on a shared machine can leave one application and remain authenticated in the other. The protocols have answers — back-channel notifications, front-channel redirects — and platform support for them is noticeably thinner than support for login.

Where the platform does not implement it, the practical mitigation is short sessions on the forum side. It is not equivalent, and it is much better than nothing.

The failures that only appear after launch

Nobody can get in because the provider is down. Federating identity means the forum's availability now depends on another system. Keep one local administrator account that bypasses the provider, and make sure at least two people know it exists.

Names and avatars stop matching. If the main site is authoritative for display names, decide whether it updates them in the forum on every login. Updating is consistent and rewrites years of attribution when somebody changes their name; not updating leaves the two permanently out of step. Either is defensible, and choosing by accident is not.

Bans do not propagate. Suspending somebody on the main site does not remove their forum access unless the token check happens on every request rather than once at login. Worth testing deliberately, because it is the failure that matters most and it never appears on its own.

Deletion has nowhere to go. When someone asks to be deleted, decide in advance what that means for posts written under a shared identity. Removing the account and leaving the content attributed to a dangling identifier satisfies nobody. Reassigning to an anonymised placeholder, with the posts intact, is the arrangement most communities settle on.

Whether to run an identity provider at all

There is a middle path that gets overlooked. Instead of the main site acting as the provider, a dedicated one sits in front of both — Keycloak and Authentik are the two most often chosen for self-hosting, and the hosted equivalents are numerous.

The case for it is that the main site probably was not built to be an identity provider, and making it one means implementing token issuance, key rotation and consent screens in an application whose job is something else. A dedicated provider does that properly and gives you somewhere to add a second application later without repeating the work.

The case against is a third system to run, patch and back up, for an organisation that is currently struggling to keep two. If the forum is the only consumer that will ever exist, pointing it at the main site is proportionate. If a second one is genuinely coming, the provider pays for itself the moment it arrives.

A sensible order of work

Stand up the provider first and prove it works with something disposable. Configure the forum against it in a staging copy with a handful of test accounts, including one that exists only in the forum, so the reconciliation path gets exercised rather than assumed.

Then run the link-on-first-login flow with real members in small batches. Disable local registration only once the linking has been proved, because turning it off first means the first person it fails for cannot get in at all.

Keep the old login route reachable for a few weeks after the switch, even if it is not advertised. Somebody will have a bookmark straight to it, and a route that quietly still works is cheaper than the support conversation that happens when it does not.