Most public feature request boards should not sit behind single sign-on at all. A public board's point is that customers who are not your staff can read and post to it, and an SSO wall checks identity against your company directory, which a customer does not have an account in. SSO belongs to a different case: a genuinely internal board, built for your team, where every reader already has a company identity to check.
This page is one part of a larger guide. For the whole subject in one place, see self-hosting a feature request board.
Does a feature request board actually need SSO?
Not usually, and the answer depends entirely on who the board is for.
| Board type | Who can read it | Who can post | Does SSO belong here? |
|---|---|---|---|
| Fully public | Anyone | Anyone, sometimes behind a captcha or email check | No |
| Public read, gated post | Anyone | Only people with an account | Rarely. A lightweight account, email or social login, usually covers it |
| Internal only | Staff, via your identity provider | Staff | Yes. This is the case SSO is built for |
A fully public board is the normal shape for a feature request tool, deliberately: the entire value is that a customer can find it and add their voice without any onboarding step. An SSO wall in front of it does not make it more secure, it makes it empty, since the audience it exists to serve cannot get in.
A board with gated posting is a smaller step. Some tools ask for a lightweight account, an email address, a magic link, or a social login, before letting someone post or vote, mainly to cut spam. That is authentication, but it is not SSO, which specifically means signing in against your own centralised identity provider, something a customer rarely has one of.
An internal-only board is the real case: a staff-only prioritisation board, an early roadmap draft, or a review queue before something reaches a public changelog. Every one of these has an audience that already has a company identity, checked by an identity provider you already run. That is exactly the problem SSO solves, and the only one of the three where reaching for it is instinct rather than a reflex.
What's the difference between SAML and OIDC?
Both are protocols for proving identity to an application without that application handling a password itself, and either can sit in front of an internal board. They differ in shape and in where each tends to turn up.
SAML, Security Assertion Markup Language, is XML-based and older, remaining the default in many established enterprise identity providers wherever a company's tooling was connected to single sign-on years ago.
OIDC, OpenID Connect, is a layer on top of OAuth 2.0 using JSON and signed JWT tokens rather than XML. It is generally simpler to implement, and tends to be what newer, API-friendly applications reach for first.
In practice, the choice is more about what the receiving application supports than what your identity provider can do: most identity providers can speak both, so it comes down to whichever protocol the board, or the proxy in front of it, is built to handle.
What does an identity provider actually give you?
An identity provider does two things and stops there.
Authentication: it proves the person signing in really is who they claim to be, checked against the company's own directory, so the login the board trusts is the company's, not one it built and has to secure itself.
An assertion: once login succeeds, it hands back a signed statement, a SAML assertion or an OIDC ID token, carrying attributes like the person's email address and, often, which groups they belong to.
What it does not give you is authorization. It proves who someone is; deciding what they are allowed to do inside the board is still the board's own job, typically by checking the group or role the assertion carried. A working SSO connection with no authorization logic behind it just means everyone in the company can log in, not that access is controlled.
The other genuine benefit is centralised session management: one login serves every connected tool, and revoking someone's access in the identity provider revokes it everywhere at once.
Should you build auth into the board, or put it behind a proxy?
Building SAML or OIDC support directly into a board's own code is real engineering: certificate handling, assertion validation, session management, and staying current with a protocol that has plenty of edge cases most applications only discover once something breaks.
The alternative is an access-control proxy in front of the board, something like Cloudflare Access or a self-hosted gateway such as oauth2-proxy, that speaks SAML or OIDC to your identity provider and only forwards a request once the person behind it is authenticated. The board itself needs no authentication code. It can be a plain static site, because the proxy makes the access decision before a single request reaches the origin.
That distinction matters most for a board that is otherwise static files with no server behind them. Wiring a full SAML or OIDC stack in just to make it SSO-gated would mean adding a server it never previously needed, purely to serve an internal audience. A proxy in front avoids that trade entirely: the board stays what it was, and the identity check happens somewhere else.
One payment, no subscription, unlimited products.
Why is SSO usually an enterprise-tier feature?
Across this category, SSO is commonly held back for the most expensive published tier, worth knowing going in rather than discovering it after settling on a tool. Productboard is the clear example: SAML SSO, along with SCIM and audit logs, sits on Enterprise only, above its published, per-maker-priced Plus and Business tiers. Enterprise itself carries no published price. Sleekplan does the same thing: SAML SSO, for Okta, Azure AD and Auth0, is Enterprise only, above tiers that do publish a price. Two vendors doing it is a coincidence; the pattern is that the moment a buyer needs SSO, they have left the published price list.
Feature Upvote is the exception worth naming, because it is genuinely unusual: SAML 2.0 SSO is included on its regular paid plans rather than reserved for a separate enterprise tier above them, a real point in its favour if SSO is something you actually need.
If an internal, SSO-gated board is the goal, check where a candidate tool actually places SSO before assuming it sits at the tier you were planning to pay for; it is one of the more common places a published price turns out not to be the real price. And if the board sits behind a proxy of your own rather than the vendor's SSO, this becomes far less relevant. See feature request tools for how the category's pricing and tiers compare more broadly, and security headers for a public feedback page for what still needs attention on the traffic that reaches the origin, proxy or not.
Frequently asked questions
Should a public feature request board ever require login just to read it?
Rarely, and doing so works against the reason most companies run one. A public board's value comes from being discoverable and easy to add a voice to; a login wall to even read it removes both. If some content genuinely needs to stay private, an internal board kept separate from the public one is the more honest solution.
Can a customer-facing board use SSO to make signing in more convenient, without gating it to staff only?
That is describing something else: a social or federated login option, offered as a convenience alongside other ways to post. It is not SSO in the enterprise sense, which specifically means authenticating against your company's identity provider, something a customer does not have an account in.
What is SCIM, and does a small internal board need it?
SCIM automatically provisions and deprovisions user accounts from an identity provider, so removing someone from a company directory group automatically removes their access to a connected tool. For a small board, manual access management is often fine; SCIM earns its keep once manual upkeep becomes a genuine chore.
Does a static site need to change to sit behind an access proxy?
No, and that is the point of the approach. The proxy handles authentication before a request ever reaches the site, so the site keeps serving the same static files it always did. Nothing about the site's own code needs to know SSO exists.
What happens to access when someone leaves the company?
With SSO in front of the board, removing that person from the identity provider revokes their access everywhere the moment their session next needs to reauthenticate. Without SSO, whoever manages the board has to remove them directly, which is the kind of manual step that quietly gets missed.