Ory Oathkeeper: a Zero Trust identity and access proxy for HTTP APIs

The problem Ory Oathkeeper removes from application code

Most services end up implementing the same three things: parse a token or session cookie, decide whether this caller may touch this route, and pass the caller's identity downstream. Duplicating that logic in every service makes policy changes expensive and makes it easy for one service to disagree with another. Ory Oathkeeper moves that work into a separate process. The README describes it as an Identity & Access Proxy (IAP) and Access Control Decision API that authorizes HTTP requests based on sets of Access Rules, following the BeyondCorp model designed by Google and securing applications in Zero-Trust networks. The intended audience is platform and infrastructure engineers who already run a gateway or proxy and want authorization to be a configuration concern rather than a per-service code concern. The README lists integration paths for Ambassador through its auth service, Envoy through the External Authorization HTTP Filter, AWS API Gateway through Custom Authorizers, and Nginx through Authentication Based on Subrequest Result. That list is the clearest statement of who this is for: teams whose traffic already passes through one of those layers.

Access rules, authenticators and mutators: the mechanism

The unit of configuration is the access rule. A rule matches an incoming request and names the strategies that handle it, which is why the README frames the project as authorizing requests based on sets of Access Rules rather than as a policy language in its own right. The repository layout reflects this split: rule/ holds the rule engine, middleware/ holds the pipeline stages, proxy/ holds the proxying behaviour, and api/ holds the decision API surface. The go.mod file shows the supporting pieces, including github.com/ory/ladon, github.com/ory/fosite, github.com/go-jose/go-jose/v3 and github.com/golang-jwt/jwt/v5, which are the libraries behind policy evaluation and token handling. The data flow in the proxy mode is straightforward: a request arrives, Oathkeeper authenticates it, evaluates the matching rule, and then mutates the request with identity information before forwarding it upstream. The README calls out mutating requests with identity information as a distinct responsibility, which is what lets a backend read the caller's identity from headers instead of decoding a token itself. In the decision mode, the same evaluation happens but the answer is returned to the calling gateway, which enforces it. That second mode is what makes the Envoy and Nginx integrations possible without Oathkeeper sitting in the data path as a full proxy.

Installing Ory Oathkeeper and running a first configuration

The README does not carry install commands. It points to the Ory Developer Documentation install guide at https://www.ory.com/docs/oathkeeper/install, which the README says explains how to install Oathkeeper on Linux, macOS, Windows, and Docker, how to configure access rules and authentication strategies, and how to deploy to Kubernetes and other orchestration systems. The repository does ship a docker-compose.yml, and its contents are the most concrete deployment example available here. The compose file builds a local image from Dockerfile-dc, publishes ports 4455 and 4456, and starts the server with a config file mounted from ./.docker_compose:

services:
  oathkeeper:
    build:
      context: .
      dockerfile: Dockerfile-dc
    ports:
      - "4455:4455"
      - "4456:4456"
    command: serve --config=/etc/config/oathkeeper/config.yaml

The same file sets TRACING_PROVIDER=jaeger and points the Jaeger agent at jaeger:6831, with a second service running jaegertracing/all-in-one and exposing its UI on port 16686. If you bring the stack up, the expectation from the compose file is that Oathkeeper serves on 4455 and 4456 and that traces appear in the Jaeger UI. The repository also contains install.sh at the top level, and the Makefile builds the binary and helper tooling from source, but neither the README nor the Makefile documents the flags for a fresh production install. Treat the compose file as a development harness and read the install guide before pointing real traffic at it.

Where Ory Oathkeeper is the wrong tool

Oathkeeper only sees HTTP(S) requests. The README describes it as authenticating, authorizing, and mutating incoming HTTP(s) requests, so anything that does not speak HTTP, such as a database protocol or a message broker, is outside its scope and needs a different enforcement point. The second limitation is operational rather than technical. The README states that the open source distribution is a fit for individuals, researchers, hackers, and companies that want to experiment, prototype, or run unimportant workloads without SLAs, and that if you run Oathkeeper as part of a business-critical system you should use a commercial agreement to reduce operational and security risk. It then lists what the Ory Enterprise License adds: additional enterprise features not available in the open source version, regular security releases including CVE patches with service level agreements, support for advanced scaling and multi-tenancy, premium support, and access to a private Docker registry with enterprise builds. For guaranteed CVE fixes and current enterprise builds in production, the README says you need a valid Ory Enterprise License. That is a real constraint on the open source path, and it is stated by the project itself rather than inferred. A team that needs contractual patch timelines should read that paragraph before designing around the open source distribution. A third case is small single-service deployments: if one application already validates tokens and the policy fits in a few lines of code, adding a separate proxy process introduces a network hop and another component to operate without removing much work.

How Ory Oathkeeper differs from running policy inside a gateway

The obvious alternative is to configure authorization directly in the gateway you already run, using Envoy's own filter configuration or Nginx's auth_request with an internal endpoint. The difference is where the rule lives and who owns it. With gateway-native configuration, the policy is expressed in that gateway's configuration language and changes ship with gateway config. Ory Oathkeeper keeps the rules in its own format and exposes them through a decision API, so the same rule set can serve Envoy, Nginx, AWS API Gateway and Ambassador without being rewritten four times. That matters when more than one ingress technology is in play, which is common in organisations that have grown by acquisition or that run different stacks per environment. The trade-off is a second component whose availability sits in the request path, plus a rule format you have to learn and keep in sync with the routes your gateway knows about. For a single gateway and a small policy surface, gateway-native configuration is fewer moving parts. For several gateways and a policy that changes independently of them, the decision API is the point of the design. The README also notes deployment as an API Gateway plugin or standalone proxy, and both proxy and sidecar deployment modes, so the same rule set can be consumed in more than one topology.

Maintenance, releases and licence implications

The repository is not archived, and the last push was on 2026-07-27. Recent releases listed in the repository are v26.2.0 on 2026-03-20, v25.4.0 on 2025-11-07, and v0.40.9 on 2025-01-30, which shows a version scheme that moved from 0.x to date-based numbering between those releases. The top-level UPGRADE.md file exists, and its presence is the signal that upgrades are expected to need attention rather than being drop-in. Anyone planning a version jump should read it alongside CHANGELOG.md before rolling out. The licence is Apache-2.0, which permits commercial use, modification and redistribution under the terms of that licence; the repository also ships a LICENSE file and a licenses target in the Makefile that checks open-source licences. The distinction that matters commercially is not the open source licence but the enterprise layer: the README separates the Apache-2.0 core from the Ory Enterprise License, which covers CVE patches with SLAs, enterprise features, multi-tenancy support and a private Docker registry. Nothing here is legal advice, and teams with procurement or compliance requirements should read the LICENSE file and the Ory Enterprise License terms directly rather than relying on a summary.

Editorial conclusion

Adopt Ory Oathkeeper if you want authentication and authorization lifted out of application code and expressed as access rules in front of an existing gateway or as a standalone proxy, and if you are comfortable running the open source distribution without an SLA. Do not adopt it if you need guaranteed CVE patching, enterprise features or vendor support under contract, because the README ties those to a commercial Ory Enterprise License. Before committing, verify the access rule schema in your own deployment, confirm how your gateway consumes the decision API, and decide whether the open source or enterprise distribution matches your operational requirements.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ory/oathkeeper on GitHub
3. Project website
4. README
5. Releases