// the find
authorizerdev/authorizer
Your data, your control. Fully open source, authentication and authorization. No lock-ins. Deployment in Railway in 120 seconds || Spin a docker image as a micro-service in your infra. Built in login page and Admin panel out of the box.
Authorizer is a self-hosted OAuth2/OIDC auth server written in Go that connects to your own database — 13+ backends supported, from Postgres to DynamoDB to ArangoDB. It handles social logins, MFA, magic links, RBAC, and now fine-grained authorization via OpenFGA. v2 is recent and still in RC. For teams who want to own user data without writing auth from scratch.
1. OIDC compliance is genuinely thorough — the integration test suite covers hybrid flow, backchannel logout, JWKS multi-key rotation, RP-initiated logout, and userinfo scope filtering. This is not surface-level OAuth bolted on top. 2. 13+ database backends including Cassandra, DynamoDB, ScyllaDB, and ArangoDB is practically unique in this space. Most self-hosted auth servers give you Postgres-or-nothing. 3. OpenFGA integration for relationship-based access control — not just role checks, but arbitrary entity-relationship policies. That's a real enterprise feature, not a roadmap promise. 4. The integration test surface is broad and hits actual HTTP/GraphQL/gRPC flows against a running server, not mocked unit tests.
1. v2 dropped env var configuration entirely — everything is CLI args now. The README already includes a workaround Dockerfile using shell-form CMD to re-add env var expansion at runtime. That's a significant DX regression for Docker and Kubernetes deployments where env vars are the deployment primitive. 2. GraphQL is the primary API. Most auth middleware, SDKs, and client integrations in the ecosystem speak REST. The REST surface exists but reads like an afterthought. 3. Supporting 13 databases across a security-critical service means each backend gets proportionally less production exposure and bug scrutiny — the ArangoDB and Couchbase backends almost certainly have fewer than five reported production issues combined. 4. Sessions are in-memory by default and evicted on restart unless you configure Redis. This is documented, but it's the kind of default that catches people who spin it up to evaluate and end up with real users before adding Redis.