We are in the process of transitioning from Ory Oathkeeper to Istio JWT access strategy. This document explains the differences between those two strategies and compares their configuration.
This table lists all possible configuration properties of the Ory Oathkeeper JWT access strategy and their corresponding properties in Istio:
Ory Oathkeeper | Required | Istio | Required | |
---|---|---|---|---|
jwks_urls | YES | → | authentications.jwksUri | YES |
trusted_issuers | NO | → | authentications.issuer | YES |
token_from.header | NO | → | authentications.fromHeaders.name authentications.fromHeaders.prefix |
NO |
token_from.query_parameter | NO | → | authentications.fromParams | NO |
token_from.cookie | NO | → | Not Supported | - |
target_audience | NO | → | authorizations.audiences | NO |
required_scope | NO | → | authorizations.requiredScopes | NO |
scope_strategy | NO | → | Not Supported | - |
jwks_max_wait | NO | → | Not Supported | - |
jwks_ttl | NO | → | Not Supported | - |
allowed_algorithms | NO | → | Not Supported | - |
Warning
Istio JWT is not a production-ready feature, and the API might change.
These are sample APIRule custom resources (CRs) of both Ory Oathkeeper and Istio JWT access strategy configuration for a Service.
apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
name: service-secured
spec:
gateway: kyma-system/kyma-gateway
host: foo.bar
service:
name: foo-service
namespace: foo-namespace
port: 8080
rules:
- path: /.*
methods: ["GET"]
mutators: []
accessStrategies:
- handler: jwt
config:
trusted_issuers:
- $ISSUER1
- $ISSUER2
jwks_urls:
- $JWKS_URI1
- $JWKS_URI2
required_scope:
- "test"
target_audience:
- "example.com"
- "example.org"
token_from:
header: X-JWT-Assertion
apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
name: service-secured
namespace: $NAMESPACE
spec:
gateway: kyma-system/kyma-gateway
host: foo.bar
service:
name: foo-service
namespace: foo-namespace
port: 8080
rules:
- path: /.*
methods: ["GET"]
mutators: []
accessStrategies:
- handler: jwt
config:
authentications:
- issuer: $ISSUER1
jwksUri: $JWKS_URI1
fromHeaders:
- name: X-JWT-Assertion
prefix: "Kyma "
- issuer: $ISSUER2
jwksUri: $JWKS_URI2
fromParameters:
- "jwt_token"
authorizations:
- requiredScopes: ["test"]
audiences: ["example.com", "example.org"]
- requiredScopes: ["read", "write"]
Warning
Both jwks_urls
and trusted_issuers
must be valid URLs. Although HTTP is allowed, it is recommended that you use only HTTPS endpoints.
Warning
You can define multiple JWT issuers, but each of them must be unique.
Warning
We support only a single fromHeader
or a single fromParameter
for a JWT issuer.
When you use Ory Oathkeeper, the APIRule JWT access strategy configuration is translated directly as authenticator configuration in the Ory Oathkeeper Access Rule CR. See the official Ory Oathkeeper JWT authenticator documentation to learn more.
With Istio JWT access strategy, for each authentications
entry, an Istio's Request Authentication resource is created, and for each authorizations
entry, an Authorization Policy resource is created.
Istio JWT access strategy only supports header
and cookie
mutators. Learn more about supported mutators.
Istio doesn't support regex type of path matching in Authorization Policies. Ory Oathkeeper Access Rules and Virtual Service do support this feature.
Istio doesn't support configuring a JWT token from cookie
, and Ory Oathkeeper does. Istio supports only fromHeaders
and fromParams
configurations.
Using Istio as JWT access strategy requires the workload behind the Service to be in the service mesh, for example, to have the Istio proxy injected. Learn how to add workloads to the Istio service mesh.
Previously, when using ORY Oathkeeper, if you called a secured workload without a JWT token, it resulted in the 401
error. This behavior has changed with the implementation of Istio-based JWT. Now, calls made without a token result in the 403
error. To learn more, read the Istio documentation on RequestAuthentication and AuthorizationPolicy.
Istio JWT uses the istio-sidecar
container to validate requests in the context of the target Pod. Previously, in-cluster requests were allowed in the ory-oathkeeper
context because request validation happened within the ory-oathkeeper
Pod. Now, these requests fail unless they are explicitly permitted.