Skip to main content

Platform Authentication

Authentication in Qefro depends on the surface:

SurfaceMechanism
Admin Console / Internal Portal usersEmail+password (OTP verify on signup), session JWT
Website WidgetPublishable widget token (Authorization: Bearer / ?token=)
End-user identity for toolsHost JWT/session via identify() headers
Super AdminSeparate /api/v1/admin/auth/login
GraphQLSame user JWT on POST /graphql
MetricsOptional METRICS_AUTH_TOKEN bearer when not public

Introduction​

User auth routes live under the API (REST + GraphQL). Abuse controls rate-limit login/OTP/forgot/reset (e.g. login ~20 / 15 min per email). Sessions can be listed and revoked (/api/v1/me/sessions, org admin session revoke).

Why it exists​

Customer AI, Employee AI, and Admin Console have different trust levels. Mixing them would either over-expose tools or block legitimate embeds.

Concepts​

  • User JWT — org member session for console/portal/REST
  • Widget token — site embed key; rotatable
  • End-user token — your customer’s JWT/session for Business Tools
  • Super Admin — platform operator, not tenant Owner

Architecture​

Workflow​

Secure a production tenant

  1. Owner account — Strong password; verify email.
  2. Invite Admins — Prefer Admin over sharing Owner login.
  3. Rotate widget token if leaked — Update every embed.
  4. Revoke sessions on offboarding — me/sessions or org member sessions.

Code examples​

# Health is public
curl -sS https://api.qefro.com/health

# Authenticated REST example
curl -sS -H "Authorization: Bearer $USER_JWT" \
  https://api.qefro.com/api/v1/org/roles

Best practices​

  • Never put User JWTs in the website widget snippet
  • Use identify() only for customer end users, not to impersonate org Admins
  • Review org audit logs after role changes

Security notes​

FAQ​

Is SSO/SAML available?
SSO/SAML is on the Enterprise roadmap — contact Sales for timeline.