authorizer

Authorizer

Open-source authentication and authorization for your applications.
Bring your own database and stay in control of user data.

Documentation · OAuth 2.0 / OIDC · v1 → v2 migration · Contributing · Discord

Authorizer is an open-source authentication and authorization server you can self-host. Connect any supported database (13+ backends including Postgres, MySQL, SQLite, SQL Server, YugaByte, MariaDB, Cassandra, ScyllaDB, MongoDB, ArangoDB, DynamoDB, and Couchbase) and run OAuth2/OIDC, social login, MFA, magic links, RBAC, webhooks, and email templates from one place.

v2 note: Authorizer v2 uses CLI arguments for all configuration. The server does not read from .env or OS environment variables. Pass config when starting the binary (e.g. ./authorizer --client-id=... --client-secret=...). See MIGRATION.md.

Quick start (local)

Prerequisites: Go ≥ 1.24 (see go.mod).

git clone https://github.com/authorizerdev/authorizer.git
cd authorizer
make dev

make dev runs the server with SQLite and development defaults (RS256 keys, sample client credentials). Open the URL printed in the logs (default port 8080) and sign in with --admin-secret (admin in dev).

For production builds, tests, and Docker, see Getting Started below.

Introduction

We offer the following functionality

• ✅ Sign-in / Sign-up with email ID and password
• ✅ Secure session management
• ✅ Email verification
• ✅ OAuth2 and OpenID Connect compatible APIs (IdP, Relying Party/broker, and both simultaneously for multi-tenant SSO)
• ✅ Machine-to-machine (service-to-service) authentication with client_credentials grant and secretless workload identity (RFC 7523 client_assertion, Kubernetes projected ServiceAccount tokens, TokenReview). Works out of the box on EKS, GKE and AKS, which publish a public OIDC issuer and JWKS by default. Clusters left on the default issuer (kubernetes.default.svc, e.g. kubeadm/kind) publish private addresses that Authorizer's SSRF guard refuses — point jwks_url at a reachable mirror of /openid/v1/jwks (key_source_type: static_jwks_url); issuer_url only has to match the token's iss and is never fetched. Verified by make test-k8s. SPIFFE JWT-SVID is preview: its draft (draft-schwenkschuster-oauth-spiffe-client-auth-00) expired 2026-01-02, is not WG-adopted, and its assertion-type URN is not IANA-registered, so the value may change
• ✅ Agent-to-agent (A2A) delegation via RFC 8693 token-exchange with nested act chains and scope attenuation
• ✅ APIs to update profile securely
• ✅ Forgot password flow using email
• ✅ Social logins (Google, GitHub, Facebook, LinkedIn, Apple, Discord, Twitter, Twitch, Roblox, Microsoft)
• ✅ WebAuthn / passkey registration and login (FIDO2 security keys, Windows Hello, Touch ID, Face ID, etc.)
• ✅ Role-based access management
• ✅ Fine-grained authorization (ReBAC via embedded OpenFGA)
• ✅ Password-less login with magic link
• ✅ TOTP-based multi-factor authentication
• ✅ SMS OTP via Twilio
• ✅ Email OTP as an MFA factor
• ✅ Email templating
• ✅ Webhooks
• ✅ Enterprise SSO — SAML 2.0 as Service Provider (upstream IdP) and Identity Provider (downstream SP), OIDC broker, verified email domains, and home realm discovery
• ✅ SCIM 2.0 user and group provisioning with RFC 7644 compliance
• ✅ Multi-tenant / org-scoped admin roles and isolation
• ✅ GraphQL, REST, gRPC, and MCP APIs (all transports share the same service layer for public auth operations)
• ✅ Remote MCP server for AI agents — OAuth 2.1 protected, RFC 9728 discovery, RFC 8707 audience-bound tokens
• ✅ Admin API — user management, webhooks, email templates, audit logs, and FGA model/tuples over GraphQL, gRPC, and REST transports
• ✅ Rate limiting and security hardening (CSRF, CORS, HSTS, CSP, trusted proxies)
• ✅ Prometheus metrics and health/readiness endpoints

Roadmap

Shipped

• ✅ Go SDK — user + admin client, protocol selection (gRPC / REST / GraphQL)
• ✅ JavaScript / TypeScript SDK — v3.3.0; user + admin client, GraphQL + REST
• ✅ Python SDK — authorizer-py v0.2.0 (v0.3.0 in pre-release: pip install --pre authorizer-py); sync + async clients, admin API
• ✅ React SDK — v2.0.7 (v2.2.0 on the rc tag); protocol prop, pre-built login/signup components
• ✅ Vue SDK — beta; no admin client or protocol selection yet
• ✅ Svelte SDK — beta; no admin client or protocol selection yet
• ✅ Kubernetes Helm Chart (v2.2.1, appVersion 2.3.0)
• ✅ Render one-click deploy
• ✅ Edge deployment via Fly.io

Planned

• Flutter SDK — repository exists; not yet published to pub.dev
• Migration guides for SSO/SAML/SCIM setup (coming soon)
• React Native SDK
• Android Native SDK
• iOS native SDK
• PHP SDK
• WordPress plugin
• AMI / Digital Ocean Droplet / Azure
• Password-less login with mobile number and OTP SMS (non-Twilio)

Getting Started

Step 1: Get Authorizer Instance

Deploy Production Ready Instance

Deploy production ready Authorizer instance using one click deployment options available below

Deploy Authorizer Using Source Code

This guide helps you practice using Authorizer to evaluate it before you use it in a production environment. It includes instructions for installing the Authorizer server in local or standalone mode.

Prerequisites

• OS: Linux or macOS or Windows
• Go >= 1.24 (see go.mod)
• Node.js >= 18 and npm (only if building the web app and dashboard)

Project Setup

1. Fork the authorizer repository (skip if you already have access)
2. Clone: git clone https://github.com/authorizerdev/authorizer.git (or your fork URL)
3. cd authorizer
4. Fastest path: make dev — SQLite, RS256 dev keys, sample OAuth client (see Quick start)
5. Full build: make build (or go build -o build/authorizer .); optionally make build-app and make build-dashboard
6. Custom flags instead of make dev:

./build/authorizer \
  --database-type=sqlite \
  --database-url=test.db \
  --url=http://localhost:8080 \
  --jwt-type=HS256 \
  --jwt-secret=test \
  --encryption-key=test-encryption-key \
  --admin-secret=admin \
  --client-id=123456 \
  --client-secret=secret

v2: The server does not read from .env. All configuration must be passed as CLI arguments. See MIGRATION.md for the full mapping of env vars to flags.

Run with Docker

The default image runs as non-root (UID 65532). Writable mounts (SQLite under /authorizer/data, etc.) are usually root-owned, so pick one of:

1. Run as root for that container (simplest for local SQLite + volumes):

   bash复制

   docker run -p 8080:8080 -u root \
     -v authorizer_data:/authorizer/data \
     quay.io/authorizer/authorizer \
     --database-type=sqlite \
     --database-url=/authorizer/data/data.db \
     --url=http://localhost:8080 \
     --client-id=123456 \
     --client-secret=secret \
     --admin-secret=admin \
     --jwt-type=HS256 \
     --jwt-secret=test \
     --encryption-key=test-encryption-key

2. Keep non-root and make the mount writable by 65532 (good for production-style bind mounts):

   bash复制

   mkdir -p ./data && sudo chown -R 65532:65532 ./data
   docker run -p 8080:8080 \
     -v "$(pwd)/data:/authorizer/data" \
     quay.io/authorizer/authorizer \
     --database-type=sqlite \
     --database-url=/authorizer/data/data.db \
     --url=http://localhost:8080 \
     ...

3. Build from source with the root target (no -u at run time):

   bash复制

   docker build --target final-root -t authorizer:root .
   docker run -p 8080:8080 -v authorizer_data:/authorizer/data authorizer:root \
     --database-type=sqlite --database-url=/authorizer/data/data.db ...

• Port 8080 serves the app and GraphQL; use -p 8080:8080 to expose it.
• Volume authorizer_data persists the SQLite DB; use a named volume or a host path (e.g. -v $(pwd)/data:/authorizer/data).
• All config is passed as CLI arguments (the image uses ENTRYPOINT ["./authorizer"] so args after the image name go to the binary). See MIGRATION.md for the full list of flags.

Database on your laptop (Postgres, MySQL, etc.)

Inside a container, localhost / 127.0.0.1 is the container itself, not your machine. Use a host alias instead:

• **Docker Desktop (mac