How sign-in works
Understand who can get into your portal and how customers and teammates sign in: portal access channels, sign-in methods, team security, sessions, and why widget sign-in never grants admin access.
Quackback separates two questions: who is allowed in and how they sign in. This article explains both, for your customers (portal users) and your team, and how widget sign-in relates to admin access.
Where sign-in is configured
Go to Admin > Settings > Access & Security. The page has three tabs:
Tab | Controls | Learn more |
|---|---|---|
Portal access | Portal visibility, anonymous interaction, account creation, allowed email domains, allowed segments, widget sign-in, and email invites | |
Sign-in | Password and the two-factor requirement, magic link, social sign-in, and single sign-on (OIDC) | |
Audit log | A record of security-sensitive changes |
By default, Owners and Admins can open this page.
Two audiences
Audience | Who they are |
|---|---|
Portal users | Customers who submit, vote on, and comment on feedback, and who contact support. |
Team members | Your teammates. Each one has a role: Owner, Admin, Manager, Contributor, or a custom role. |
Team members can browse the public portal while signed in to Quackback. They can also be identified in your widget as a customer. That widget session never unlocks the admin dashboard (see Session types below).
Portal access channels
A public portal is open to everyone. A private portal admits visitors through these channels, checked in order:
Channel | Who it lets in | Requires |
|---|---|---|
Team | Your team members | Signed in on Quackback (admin or portal login) |
Allowed domain | Anyone whose verified email is on a listed domain | Verified email |
Email invite | A specific person you invited | Verified email |
Allowed segment | Any member of a permitted segment | Verified email |
Widget sign-in | A visitor already identified in your embedded widget | Identify users with a signed |
See Control portal access and sign-in for the full setup.
Sign-in methods
Method | Portal users | Team members |
|---|---|---|
Password | Yes (on by default) | Yes (on by default) |
Optional (off by default) | Optional (off by default) | |
10 providers: Apple, Discord, Facebook, GitHub, GitLab, Google, LinkedIn, Microsoft, Reddit, Twitter / X | The same 10 providers | |
Custom OIDC button | A "Sign in with" button for your own OpenID Connect provider | The same provider can also sign in your team |
Users at a verified domain are routed to your identity provider | Verified domains, optional enforcement, automatic account creation |
Password, magic link, and each social provider have one toggle on the Sign-in tab that applies to both the portal and the team sign-in forms. Who may enter a private portal is decided separately, on the Portal access tab. At least one sign-in method always stays enabled.
Note: On Quackback Cloud, single sign-on, the custom OIDC button, and the audit log are available on the Enterprise plan.
Team security
The Sign-in and Audit log tabs add protections for your team:
- Two-factor authentication: authenticator-app codes on top of a password, optionally required for the whole team.
- Single sign-on: connect an OIDC identity provider, verify your domains, and require SSO so company emails can only sign in through it.
- Recovery codes: break-glass sign-in when SSO is unavailable.
- Audit log: an append-only record of every security-sensitive change.
Sign-in hardening
Quackback rate-limits password and magic-link sign-in attempts per IP address and email address. It also tracks devices and emails the account owner the first time an account signs in from a new device.
Sessions
- Sessions last 7 days and refresh every 24 hours while someone is active.
- Signing out ends the session immediately.
Session types
Signing in only unlocks the place someone signed in from. A customer who uses the widget never gets admin dashboard access from that sign-in, even if you later invite them to your team.
Type | How someone gets it | What they can do |
|---|---|---|
Quackback | Signs in at your Quackback URL (admin login or the portal sign-in form) | Full team access, according to their role, if they are a team member. Otherwise customer access. |
Widget | Uses your embedded widget, as a guest or after being identified | Customer actions in the widget only. Not exports, settings, or the admin inbox. |
Portal from widget | Opens the portal from a verified widget session with Widget sign-in on | Customer access on the portal. Still not admin. |
Note: Team members can be identified in the widget. That session stays a customer session: it never unlocks the admin dashboard, exports, or the inbox. Opening the portal from the widget does not sign a teammate in, so it can't replace a dashboard login. If a customer is later added to your team, their existing widget or portal-from-widget sign-in stays a customer sign-in until they sign in on Quackback itself.
Roles
Portal users can submit, vote, and comment on your public portal. Team members get access to the admin dashboard according to their role: Owner, Admin, Manager, Contributor, or a custom role. See Understand roles and permissions.
Related articles
Was this helpful?
Your feedback shapes what we write next.