Skip to content

Latest commit

 

History

History
86 lines (61 loc) · 4.29 KB

File metadata and controls

86 lines (61 loc) · 4.29 KB
title Authentication
description Understand Quackback's sign-in methods for portal users and team members.
icon lock

Authentication

Quackback splits authentication into two concerns: who's allowed in and how they sign in. Both live on Admin → Settings → Security → Authentication, which has three tabs:

Tab Controls Doc
Portal access Visibility, allowed domains, email invites, allowed segments, widget sign-in Control portal access and sign-in
Team access Team-side 2FA and the SSO summary Configure team security
Sign-in providers Password, magic link, social OAuth, Custom OIDC — per-surface toggles Sign-in providers

Two audiences

Audience Who they are
Portal users Customers who submit and vote on feedback.
Team members Admins and members who manage feedback.

A team member can also use the public portal like any other user.

Portal access channels

A private portal admits visitors through these channels, evaluated in order:

Channel Who it lets in Requires
Team Admins and members Real authenticated session
Allowed domain Anyone whose verified email matches a listed domain Email verified
Email invite A specific person you invited Email verified
Allowed segment Any member of a permitted segment Email verified
Widget sign-in A visitor signed into your embedded widget Verified-identity widget + admin opt-in

See Control portal access for the full setup walkthrough.

Sign-in methods

Method Portal users Team members
Password Yes (on by default) Yes (on by default)
Magic link Optional (off by default) Yes (on by default)
OAuth social 10 providers (Apple, Discord, Facebook, GitHub, GitLab, Google, LinkedIn, Microsoft, Reddit, Twitter / X) Same 10 providers - GitHub and Google on by default
Custom OIDC (portal button) One OIDC button on the portal sign-in form, tier-gated Use full team SSO instead
Single sign-on Routes via verified-domain dispatch Verified domains, optional enforcement, JIT provisioning

Each method is a toggle. Turn on the combination that fits your users. At least one method always stays enabled per surface.

Team security

The Security page adds protections specific to the team:

  • Two-factor authentication: TOTP codes on top of a password, optionally required workspace-wide.
  • Single sign-on: connect an OIDC provider, verify your domains, and require SSO so company emails can only sign in through your IdP.
  • 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 and email address, tracks devices, and emails the account owner the first time an account signs in from a new device. The new-device email is on by default and configurable on the Team tab.

Sessions

  • Sessions last 7 days and refresh every 24 hours on activity.
  • Signing out invalidates the session immediately.
  • Sessions are stored in PostgreSQL and expired ones are cleaned up automatically.

Roles

Role Capabilities
User Submit, vote, and comment on the public portal.
Member Everything a user can do, plus access the admin dashboard and manage feedback.
Admin Everything a member can do, plus workspace settings, team management, and integrations.

See Roles & permissions for the full breakdown.

Next steps