Control portal access and sign-in

Choose who can see your feedback portal and how visitors sign in. Quackback keeps the two apart: Portal access decides who is allowed in, and Sign-in decides how they authenticate.

Where to find it

Go to Admin > Settings > Access & Security. The page has three tabs:

By default, Owners and Admins can change these settings. Every change to portal access, sign-in methods, or invites is recorded in the audit log.

Portal visibility

A portal is either public or private.

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

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

1. Team: your team members always have access.
2. Allowed email domains: users with a verified email on a listed domain.
3. Email invites: anyone you invited who accepted the invite.
4. Allowed segments: members of a segment you've authorized.
5. Widget sign-in: visitors who already signed in through your embedded widget.

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

Anonymous interaction and account creation

Two switches on the Portal access tab control what visitors can do without an account:

• Allow anonymous interaction: lets visitors vote, comment, and submit feedback without signing in. When it's off, every board requires sign-in to vote, comment, and submit. Viewing is not affected. It applies to both the portal and the widget.
• Let visitors create an account: lets visitors sign up on their own. Turn it off if only invited or allowed people should get accounts.

Anonymous interaction is a ceiling, not a per-board setting. Even when it's allowed, an individual board can still require sign-in, or limit an action to certain segments or your team, from the board's Access tab. See Organize feedback with boards.

When a visitor first interacts anonymously, Quackback creates a browser session for them in the background, so their action registers instantly. If they create an account later, their earlier anonymous votes are linked to it automatically.

Allowed email domains

Let in anyone with a verified email on a domain you list. This is useful for "everyone at @acme.com can see the portal" without sending individual invites.

1. Open the Portal access tab.
2. Under Allowed email domains, add a domain (for example acme.com).
3. Repeat for other domains. Domains save automatically.

Warning: Domain access requires the visitor's email to be verified. Quackback never trusts an unverified email for an allowlist match, since anyone could otherwise sign up with an address they don't own.

Email invites

Invite specific people by email. Each invite contains a magic link that signs the recipient in and gives them portal access.

1. Open the Portal access tab and find Email invites (or go to Admin > Users and open the invitations view).
2. Click Invite people.
3. Paste up to 50 email addresses, separated by commas, spaces, or new lines.
4. Optionally add a short personal message (up to 500 characters). It's included in the email.
5. Click Send invites.

Each recipient gets a branded email with your message and a sign-in link. The link is valid for 14 days. Pending invites expire after that.

Tip: Need to share a link directly, for example in Slack? On a pending invite, click Copy link to copy the same link that's in the email. Copying a link is recorded in the audit log.

Invite statuses:

Portal invites are free and never use a team seat.

Allowed segments

Use segments to give a whole group access at once, for example "everyone on our Pro plan" or "all users from a key account".

1. Open the Portal access tab.
2. Under Allowed segments, pick one or more segments.
3. The selection saves automatically.

A visitor gets in when they are signed in, belong to one of the chosen segments, and have a verified email. The verified-email check matters because segments can be based on email (for example "email ends with @acme.com"), and without verification someone could claim an address they don't own.

Note: When a segment's rules change, membership is re-evaluated. Visitors who fall out of a segment lose portal access on their next request. See Group users with segments.

Widget sign-in

If your product embeds the Quackback widget and identifies signed-in users with a signed ssoToken, you can let those visitors carry their widget identity over to the portal, with no password and no second sign-up.

1. Identify widget users with an ssoToken signed on your server. See Identify users.
2. On the Portal access tab, turn on Widget sign-in.

Visitors who open your portal from a verified widget session are signed in to the portal automatically. Behind the scenes the widget hands the portal a one-time token, so they don't sign in twice. They stay a customer on the portal: this path never grants admin access. Your teammates are not signed in this way. They land on the portal sign-in screen, or keep an existing dashboard login. See How sign-in works.

Warning: Widget sign-in needs a verified identify (an ssoToken signed on your server). Guests and inline email capture are not enough to open a private portal this way.

Sign-in methods

The Sign-in tab controls how visitors and teammates authenticate. Each method has one toggle that applies to both the portal and the team sign-in forms. At least one method always stays enabled.

Password

Email and password sign-in. Passwords are 8 to 128 characters. People can request a reset link by email.

Magic link

A one-click sign-in link sent by email. On a self-hosted instance, the toggle stays locked until email delivery is configured (one of SMTP, Amazon SES, or Resend). See Set up magic-link sign-in.

When both password and magic link are on, people can switch between them on the sign-in form.

Social sign-in

Quackback has 10 built-in social providers. A provider's toggle stays locked until you've saved its Client ID and Client Secret. Credentials are stored encrypted in Quackback. See Set up OAuth providers.

Custom OIDC sign-in button

To give customers a "Sign in with" button for your own OpenID Connect identity provider, add the provider in the Single sign-on (OIDC) card on the Sign-in tab. On the provider's page, turn on Show sign-in button, set its display name and logo, and leave New account role at User (portal only) so people who sign in this way get customer access. The connection form recognizes common providers (such as Microsoft Entra ID, Okta, Google Workspace, and OneLogin) and fills in sensible defaults.

The redirect URI to register with your provider is shown on the provider's page. New providers use https://YOUR_DOMAIN/api/auth/callback/<registration-id>. Providers set up before version 0.14 keep /api/auth/oauth2/callback/<registration-id> until you click Switch to new URI.

Note: On Quackback Cloud, OIDC identity providers are available on the Enterprise plan.

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

When every sign-in method is off

The Sign-in tab won't let you turn off the last enabled method. If every method ends up off anyway (for example, after editing a configuration file or the database directly), the portal degrades gracefully:

• The Log in and Sign up buttons are hidden from the portal header.
• Team members can still sign in at /admin/login.
• Portal users on a verified SSO domain still see the sign-in buttons, and their email is routed into the SSO flow. You can use this to run an SSO-only portal.

Related articles

• How sign-in works
• Set up magic-link sign-in
• Set up OAuth providers
• Set up single sign-on
• Group users with segments
• Manage your team