Pick who can see your feedback portal and which sign-in methods they use. Quackback separates the two concerns: Portal access decides who's allowed in, and Sign-in providers decides how they authenticate.

Configure both at Admin → Settings → Security → Authentication. The page has three tabs:

Tab	Controls
Portal access	Visibility, allowed domains, email invites, allowed segments, widget sign-in
Team access	Team-side 2FA and the SSO summary — see Security
Sign-in providers	Password, magic link, social OAuth, and Custom OIDC for both surfaces

For team-wide single sign-on with verified domains and enforcement, see Single sign-on.

Portal access

A portal is either public or private. Public portals are open to everyone, including unsigned visitors. Private portals admit only the visitors you authorize through the channels below.

Visibility	Who gets in
Public	Anyone, no sign-in required. Signed-in users can still vote, comment, and post.
Private	Your team, plus anyone covered by an allow-channel below.

Switching from Public to Private hides your portal from anonymous visitors immediately. Confirm the change in the dialog that appears. You can flip it back at any time.

A private portal evaluates these channels in order. The first match grants access.

Team — admins and members always have access.
Allowed email domains — verified-email users on a listed domain.
Email invite — anyone you've sent and who's accepted a portal invite.
Allowed segments — members of a segment you've authorized.
Widget sign-in — visitors who already signed in via your embedded widget.

Visitors who don't match any channel are redirected to sign in. Authenticated visitors who still don't match see a clear "no access" screen with sign-out and account links.

Allowed email domains

Auto-admit any verified-email user whose address ends with a domain you list. Useful for "all @acme.com employees can see the portal" without sending individual invites.

Open the Portal access tab.
Under Allowed email domains, type a domain (e.g. acme.com) and press Enter.
Repeat for additional domains. Domains save automatically.

Domain access requires the visitor's email to be verified. Quackback never trusts an unverified email claim for an allowlist match — anyone could otherwise sign up with someone@acme.com they don't own.

Email invites

Invite specific people by email. Each invite is good for a magic link that signs the recipient in and grants portal access automatically.

Open the Portal access tab (or Admin → Users → Invitations).
Click Invite people.
Paste up to 50 email addresses separated by commas, spaces, or newlines.
Optionally add a short personal message (up to 500 characters) — it's included in the email.
Click Send invites.

Each recipient gets a branded email with the personal message and a sign-in link. The link is good for 14 days; pending invites expire automatically after that.

Need to share a link directly (e.g. in Slack)? On any pending invite row, click Copy link to grab the same magic link that's in the email. The link is recorded in the audit log so you can see who minted it.

Track invite status from Admin → Users → Invitations:

Status	Meaning
Pending	Sent, not yet accepted. Resend or revoke from the row.
Accepted	Recipient followed the link and now has portal access.
Revoked	Admin cancelled the invite. The link no longer works.
Expired	Pending past the 14-day window. Send a fresh invite to retry.

Every send, resend, accept, revoke, link-mint, and expiry is recorded in the audit log.

Allowed segments

Use segments to grant portal access to a whole cohort at once — for example, "everyone on the Pro plan" or "all users from @bigcorp.com".

Open the Portal access tab.
Under Allowed segments, pick one or more segments from the multi-select.
The selection saves automatically.

Segment access works for any authenticated visitor whose principal is a member of one of the chosen segments and has a verified email. The verified-email guard mirrors the domain and invite channels: dynamic segments can predicate on email (e.g. "email ends with @acme.com"), so without verification an attacker could claim someone else's address and walk in.

If you change a segment's rules, membership re-evaluates on the next hourly run (or trigger it manually from the Segments list). Visitors who fall out of a segment lose portal access on their next request.

When your product embeds the Quackback widget and uses verified identity, you can let those visitors carry their widget identity over to the portal — no password, no second sign-up.

Verify your widget runs with Verified identity only on (Admin → Settings → Widget).
On the Portal access tab, toggle Widget sign-in on.

Visitors who open your portal from inside a verified widget session are signed into the portal automatically. Behind the scenes the widget mints a one-time token (OTT) and the portal exchanges it for a session.

Widget sign-in requires HMAC-verified widget identity. If you turn off Verified identity only in the Widget settings, the widget falls back to email-capture mode and Quackback refuses to grant portal access through this channel — email-capture trust isn't strong enough to imply portal access.

The Sign-in providers tab controls how visitors authenticate. Each method has independent toggles for the Portal (your customers) and Team (your admins). At least one method per surface always stays enabled.

Method	Default (Portal)	Default (Team)
Password	On	On
Magic link	Off	On
Social OAuth (10 providers)	Off (configure first)	GitHub & Google on
Custom OIDC button	Off	Use SSO instead

Password

Email + password sign-in. 8 to 128 characters. Users request reset links by email.

Magic link

One-click sign-in link sent by email.

Default: Off
Requires: Email delivery configured (SMTP or Resend). The toggle stays locked off until email is set up.

When both Password and Magic link are enabled, users can switch between methods on the sign-in form.

OAuth providers

Quackback ships with 10 built-in social providers. Configure each one once and enable it for the Portal, Team, or both. Credentials are stored encrypted in the database; no environment variables to set.

A provider's toggle stays locked off until you've saved its Client ID and Client Secret. See OAuth providers for the per-provider walkthrough.

Custom OIDC

Bring your own OpenID Connect identity provider for a single button on the portal sign-in form. The configuration form auto-detects common providers (Microsoft Entra ID, Okta, Google Workspace, OneLogin) from the issuer URL and prefills sensible defaults.

Default: Off
Availability: Plans with the Custom OIDC feature. Lower tiers see a tier-lock badge.

For full team-wide SSO with verified domains, enforcement, and JIT provisioning, use Single sign-on instead.

Anonymous interaction

Visitors can vote, comment, and submit feedback without creating an account when the workspace allows it. A single workspace switch, Allow anonymous interaction, controls all three. Find it at Admin → Settings → Moderation. It applies to both the portal and the embeddable widget.

When it's off, every board requires sign-in to vote, comment, and submit. Viewing is unaffected.

This switch is a ceiling, not a per-board setting. Even when anonymous interaction is allowed, an individual board can still require sign-in or restrict an action to segments or your team on its Access tab.

When a visitor first interacts anonymously, a browser session is created transparently. Their action registers instantly with no sign-in prompt. If they later create an account, their existing anonymous votes are linked over automatically.

Anonymous sign-in is rate-limited to 50 new anonymous sessions per IP per hour. Once a visitor has a session, casting or un-casting votes doesn't count against the limit.

The Sign-in providers tab refuses to disable the last enabled method, but if you've edited the configuration file or the database directly and turned every portal sign-in method off, the portal degrades gracefully:

The Log in and Sign up buttons are hidden from the public portal header.
Team members can still sign in by visiting /admin/login directly. The Team and Portal toggles are independent.
Portal users on a verified SSO domain still see the Log in / Sign up buttons. The portal email dispatcher routes matching addresses into the SSO flow even when no other method is enabled. You can run an "SSO-only portal" by turning off every other portal method while keeping Single sign-on configured for your domain.

Access control

Role	Can view	Can modify
Admin	Yes	Yes
Member	No	No

Every change to portal access, sign-in providers, or invites is recorded in the audit log.

Next steps

Team Members — manage your team and their access
Magic link sign-in — passwordless email sign-in
OAuth providers — per-provider setup walkthroughs
Single sign-on — team-wide SSO with verified domains
Segments — group users for inbox filtering and access