Skip to main content

Overview

Quinn uses session-based authentication with HTTP-only cookies. This provides security while maintaining simplicity for client applications.

Authentication Flow

1

Login

Send your credentials to the login endpoint:
Response:
The server returns a Set-Cookie header with sessionId (HTTP-only, secure).
2

Make Authenticated Requests

Include the session cookie in subsequent requests:
3

Logout

End your session:
This invalidates the session and clears the cookie.

Session Management

Session Duration

  • Default: 7 days
  • Activity Extension: Sessions extend on each request
  • Absolute Maximum: 30 days

Session Storage

Sessions are stored in PostgreSQL with the following data:
  • User ID
  • Organization ID
  • Email
  • Role
  • Created/Expires timestamps
  • Impersonation state (for support)

Multi-Tenant Isolation

All API requests are automatically scoped to your organization. You can only access data belonging to your organization.
When you authenticate, your session includes:
  • userId: Your unique user ID
  • organizationId: Your organization’s ID
  • role: Your permission level
Every API endpoint validates:
  1. ✅ Session exists and is valid
  2. ✅ User belongs to organization
  3. ✅ User has required permissions for that endpoint

Role-Based Access Control

Quinn has three role levels:

Permission Examples

Code Examples

JavaScript/TypeScript

Python

cURL

Security Best Practices

Never send credentials over HTTP. Session cookies are marked as Secure and will only be sent over HTTPS connections.
If building a web application, implement CSRF tokens for state-changing operations (POST, PUT, DELETE).
Encourage users to change passwords every 90 days. Quinn supports password requirements via organization settings.
Never hardcode credentials. Use environment variables:
Quinn rate-limits login attempts (10/minute per IP). Monitor for suspicious activity via admin dashboard.

Error Handling

Common Authentication Errors

Error Response Format

Advanced: Impersonation (Support)

Impersonation is only available to super admins for customer support purposes.
Super admins can impersonate users to debug issues:
While impersonating:
  • All requests are scoped to the impersonated user’s organization
  • Audit log tracks all actions taken
  • Destructive actions (delete user, delete organization) are blocked
  • Session includes isImpersonating: true flag
To end impersonation:

Testing Authentication

Use the API playground to test authentication:

Try it in the Playground

Test the login endpoint with your credentials

Troubleshooting

Solutions:
  • Verify session cookie is being sent (check browser DevTools → Network → Cookies)
  • Re-login to get fresh session
  • Check if session expired (7 day limit)
Verify:
  • Your role is admin or super_admin (check /api/auth/me)
  • You’re accessing the correct organization
  • Feature is enabled in organization settings

Next: Learn about Core Concepts or explore the API Reference.