# Authorizer: self-hosted auth server with 13+ database backends and a v2 CLI-only configuration

> Authorizer is an Apache-2.0 Go server that runs OAuth2, OIDC, WebAuthn, SAML and ReBAC from one self-hosted binary connected to any of 13 or more database backends. Version 2.4.1 drops environment variable configuration entirely: all settings pass as CLI arguments, which makes the v1 to v2 migration a required rewrite for any deployment that relied on .env files.

**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.

- Repository: https://github.com/authorizerdev/authorizer
- Website: https://authorizer.dev
- Stars: 2,107 · Forks: 222
- Language: Go
- License: Apache-2.0
- Published: 2026-10-09 · Updated: 2026-10-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/authorizerdev-authorizer

## v2 drops .env configuration: all settings pass as CLI arguments with no environment variable fallback

Authorizer v2 removes the environment variable configuration model from v1. An .env.sample file in the repository states this directly: v2 does not read from .env, and all configuration must pass as CLI arguments when starting the server. Any v1 deployment using a .env file breaks silently in v2 unless every variable is remapped to a flag.

Three flags are required: --url (the server's public URL), --client-id, and --client-secret. Setting --admin-secret provides the admin console password. An example from .env.sample shows the full pattern:

```bash
./authorizer --database-type=sqlite --database-url=data.db \
  --client-id=... --client-secret=... --admin-secret=...
```

MIGRATION.md contains the full mapping from v1 environment variables to v2 CLI flags. DATABASE_TYPE becomes --database-type, DATABASE_URL becomes --database-url, JWT_TYPE becomes --jwt-type, JWT_SECRET becomes --jwt-secret. By default the interactive playground is on; --enable-playground=false turns it off. Custom token scripts pass through --custom-access-token-script.

This design separates configuration from the runtime environment, which fits container deployments where secrets arrive through the orchestrator rather than a mounted file. Any previous automation that sourced .env before starting the v1 server must be rewritten entirely before upgrading.

## Starting from source with make dev, or from Docker on ports 8080 and 9091

Building from source requires Go 1.26.6, which is the version pinned in go.mod (the README states the floor as ≥ 1.24). Three commands get a local instance running:

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

`make dev` starts the server with SQLite and RS256 JWT signing on port 8080. In dev mode, the admin password comes from --admin-secret, which is `admin` by default. Opening the URL printed in the startup logs shows the admin console immediately.

docker-compose.yaml maps two ports: 8080 for the main server and 9091 for a second endpoint. Inside the Dockerfile, the build starts from golang:1.27-alpine3.23, uses BuildKit cache mounts to speed up repeated builds, and produces a trimpath binary with -ldflags "-w -s". Final image runs on alpine:3.23.3.

For production, --url must match the server's public address exactly. OAuth2 redirect flows use this value to build callback URLs, so a mismatch between --url and the actual hostname breaks authentication completions. No default is documented for --url, which means OAuth2 flows do not work until it is set.

## 13+ database backends share the same two flags: --database-type and --database-url

Database support in v2.4.1 covers both SQL and NoSQL backends: Postgres, MySQL, SQLite, SQL Server, YugaByte, MariaDB, Cassandra, ScyllaDB, MongoDB, ArangoDB, DynamoDB and Couchbase. A thirteenth option, LibSQL, appears in go.mod through the gorm-libsql dependency. Switching between backends changes only two flags: --database-type and --database-url, and nothing else in the server configuration needs to change.

SQLite is the default for development and requires no additional infrastructure, making it the fastest path to a working instance. DynamoDB uses the AWS SDK v2 at aws-sdk-go-v2 v1.41.5. Couchbase connects through gocb/v2 v2.6.4, and MongoDB uses the official Go driver at v1.17.9. Those version numbers are in go.mod and are the concrete versions the current build compiles against.

Three things are not documented in the README: which features require a specific database type, whether schema migrations run automatically on startup, and how schema changes across version upgrades are handled. CHANGELOG.md and MIGRATION.md are the places to check before upgrading a production deployment.

## TokenReview on Kubernetes works on EKS, GKE and AKS, but kubeadm clusters need a JWKS mirror

Authorizer supports machine-to-machine authentication via RFC 7523 client assertions and Kubernetes projected ServiceAccount tokens. A pod in a managed cluster can authenticate using its Kubernetes-issued token without storing a client secret, which removes a category of credential management from the deployment.

kubeadm and kind clusters have a specific limitation. Those environments use `kubernetes.default.svc` as the OIDC issuer by default, a private address that Authorizer's SSRF guard refuses to fetch JWKS from. Workaround: set `key_source_type: static_jwks_url` and point `jwks_url` at a reachable mirror of `/openid/v1/jwks`. `issuer_url` only needs to match the token's `iss` claim and is never fetched.

EKS, GKE and AKS publish a public OIDC issuer by default and all work out of the box. `make test-k8s` in the repository is described as the verification suite for the TokenReview path.

Agent-to-agent delegation is also available through RFC 8693 token exchange with nested `act` chains and scope attenuation. This targets workflows where one service needs to act on behalf of another within a bounded scope, distinct from a service authenticating with its own credentials.

## OpenFGA runs embedded for ReBAC alongside RBAC, and the two authorization systems are separate

Authorizer ships two authorization systems in the same binary. RBAC assigns roles to users and evaluates role membership when deciding access. ReBAC, which Authorizer calls fine-grained authorization, models relationships between objects and derives permissions from those relationships. OpenFGA provides this embedded layer, listed in go.mod at v1.18.1.

Each system expresses different things in its policy language. RBAC answers: does user X have role Y? ReBAC answers: does user X have a relationship to object Z that allows action A? A document sharing system where each document has its own owner and set of collaborators fits ReBAC naturally. Three static permission tiers (admin, user, viewer) fit RBAC without needing the added relationship model.

FGA model and tuple management are accessible through the Admin API over GraphQL, gRPC and REST transports. Tuples are the relationship assertions that populate the ReBAC graph. No documentation describes how RBAC and ReBAC interact when both are active simultaneously, such as whether an FGA policy can override an RBAC role decision. That boundary is not documented.

## SPIFFE JWT-SVID is preview, with an assertion URN from an expired draft

SPIFFE JWT-SVID carries a preview label for a specific reason: it implements draft-schwenkschuster-oauth-spiffe-client-auth-00, which expired on 2026-01-02. That draft is not WG-adopted, and its assertion-type URN is not IANA-registered. Because the URN value may change as the draft evolves, any production integration that embeds it becomes dependent on a moving target.

An MCP server for AI agents is listed as generally available. It uses OAuth 2.1, RFC 9728 discovery and RFC 8707 audience-bound tokens, which lets AI agents using the Model Context Protocol authenticate through Authorizer and receive tokens scoped to specific audiences rather than generic bearer tokens.

Two documentation gaps worth checking before committing to this project: audit logs are accessible through the Admin API, but their format, retention period and query interface are not described in the README beyond the API surface itself. Webhooks appear in the feature list, but the event schema, retry policy and failure handling for webhook delivery are not documented there either. Both require reading the full documentation at docs.authorizer.dev.

## SDK maturity varies: Go and JS at release, Vue and Svelte in beta, Flutter not yet published

JavaScript and TypeScript SDK at v3.3.0 covers both user and admin clients with GraphQL and REST support, making it the most complete client option outside of Go. Python SDK is at v0.2.0, with v0.3.0 in pre-release available as pip install --pre authorizer-py. React SDK at v2.0.7 (v2.2.0 on the rc tag) includes pre-built login and signup components. Go SDK covers user and admin clients with protocol selection across gRPC, REST and GraphQL, and is the only SDK that exposes all three transports today.

Vue and Svelte SDKs are both in beta and share the same gap: neither includes an admin client or protocol selection yet. A Flutter SDK repository exists but has not been published to pub.dev. For a team evaluating SDK coverage before adopting Authorizer, the practical choices today are Go, JavaScript/TypeScript, Python and React.

Deployment options beyond Docker include a Kubernetes Helm Chart at v2.2.1 (appVersion 2.3.0), Render one-click deploy and Fly.io edge deployment. Last push to the main branch was on 2026-10-06. Most recent release is v2.4.1, published on 2026-09-03, following v2.4.0 on 2026-08-19. Both releases are Apache-2.0 licensed, and the repository includes GOVERNANCE.md, MAINTAINERS.md and SECURITY.md for governance and disclosure procedures.

## Conclusion

Authorizer suits teams that want a self-hosted auth server with broad database support and no lock-in to a managed provider. CLI-only configuration in v2 works well in containers but requires migrating every v1 .env variable before upgrading. Skip it for kubeadm or kind clusters that need TokenReview without setting up a JWKS mirror, and skip SPIFFE JWT-SVID for production integrations requiring stable URNs: that draft expired on 2026-01-02. Before going to production, read MIGRATION.md if upgrading from v1, set --url to the public server address, and confirm the database backend.

## FAQ

### What is Authorizer?

Authorizer is a self-hosted authentication and authorization server written in Go that provides OAuth2, OIDC, WebAuthn, SAML, RBAC, ReBAC and social login from one binary. It supports 13 or more database backends and is released under the Apache-2.0 license.

### How does Authorizer v2 configuration differ from v1?

Version 2 does not read from .env files or environment variables. All configuration passes as CLI arguments when starting the server, such as --database-type, --database-url, --client-id and --client-secret. The full mapping from v1 environment variables to v2 flags is in MIGRATION.md.

### Which databases does Authorizer support?

Authorizer supports Postgres, MySQL, SQLite, SQL Server, YugaByte, MariaDB, Cassandra, ScyllaDB, MongoDB, ArangoDB, DynamoDB, Couchbase and LibSQL. Switching backends changes only the --database-type and --database-url flags.

### Does Authorizer support Kubernetes service account authentication?

Yes, through RFC 7523 client assertions and Kubernetes projected ServiceAccount tokens. It works out of the box on EKS, GKE and AKS, which publish a public OIDC issuer. Clusters using the default private issuer (such as kubeadm or kind) need jwks_url pointed at a reachable JWKS mirror.

### What client SDKs are available for Authorizer?

Released SDKs cover Go (user and admin), JavaScript and TypeScript (v3.3.0), Python (v0.2.0, v0.3.0 in pre-release), and React (v2.0.7). Vue and Svelte SDKs are in beta with no admin client yet. A Flutter SDK repository exists but has not been published.

## Sources

- [authorizerdev/authorizer on GitHub](https://github.com/authorizerdev/authorizer)
- [License: Apache-2.0](https://github.com/authorizerdev/authorizer/blob/main/LICENSE)
- [Project website](https://authorizer.dev)
- [README](https://github.com/authorizerdev/authorizer/blob/main/README.md)
- [Releases](https://github.com/authorizerdev/authorizer/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/authorizerdev-authorizer