<p>I have a sample application (web-app, backend-1, backend-2) deployed on minikube all under a JWT policy, and they all have proper destination rules, Istio sidecar and MTLS enabled in order to secure the east-west traffic.</p>

<pre><code>apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: oidc
spec:
  targets:
  - name: web-app
  - name: backend-1
  - name: backend-2
  peers:
  - mtls: {}
  origins:
  - jwt:
      issuer: "http://myurl/auth/realms/test"
      jwksUri: "http://myurl/auth/realms/test/protocol/openid-connect/certs"
  principalBinding: USE_ORIGIN
</code></pre>

<p>When I run the following command I receive a 401 unauthorized response when requesting the data from the backend, which is due to $TOKEN not being forwarded to backend-1 and backend-2 headers during the http request.</p>

<pre><code>$&gt; curl http://minikubeip/api "Authorization: Bearer $TOKEN"
</code></pre>

<p>Is there a way to forward http headers to backend-1 and backend-2 using native kubernetes/istio? Am I forced to make application code changes to accomplish this?</p>

<p><strong>Edit:</strong>
This is the error I get after applying my oidc policy. When I curl web-app with the auth token I get </p>

<blockquote>
  <p>{"errors":[{"code":"APP_ERROR_CODE","message":"401 Unauthorized"}</p>
</blockquote>

<p>Note that when I curl backend-1 or backend-2 with the same auth-token I get the appropriate data. Also, there is no other destination rule/policy applied to these services currently, policy enforcement is on, and my istio version is 1.1.15.
This is the policy I am applying:</p>

<pre><code>apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: default
  namespace: default
spec:
  # peers:
  # - mtls: {}
  origins:
  - jwt:
      issuer: "http://10.148.199.140:8080/auth/realms/test"
      jwksUri: "http://10.148.199.140:8080/auth/realms/test/protocol/openid-connect/certs"
  principalBinding: USE_ORIGIN
</code></pre>

<blockquote>
<p>should the token be propagated to backend-1 and backend-2 without any other changes?</p>
</blockquote>
<p>Yes, policy should transfer token to both backend-1 and backend-2</p>
<h2>There is a <a href="https://github.com/istio/istio/issues/15122" rel="nofollow noreferrer">github issue</a> , where users had same issue like You</h2>
<p>A few informations from there:</p>
<blockquote>
<p>The JWT is verified by an Envoy filter, so you'll have to check the Envoy logs. For the code, see <a href="https://github.com/istio/proxy/tree/master/src/envoy/http/jwt_auth" rel="nofollow noreferrer">https://github.com/istio/proxy/tree/master/src/envoy/http/jwt_auth</a></p>
<p>Pilot retrieves the JWKS to be used by the filter (it is inlined into the Envoy config), you can find the code for that in pilot/pkg/security</p>
</blockquote>
<h2>And another problem with that in <a href="https://stackoverflow.com/questions/54988412/keycloak-provides-invalid-signature-with-istio-and-jwt">stackoverflow</a></h2>
<p>where accepted answer is:</p>
<blockquote>
<p>The problem was resolved with two options: 1. Replace Service Name and port by external server ip and external port (for issuer and jwksUri) 2. Disable the usage of mTLS and its policy (Known issue: <a href="https://github.com/istio/istio/issues/10062" rel="nofollow noreferrer">https://github.com/istio/istio/issues/10062</a>).</p>
</blockquote>
<h2>From istio documentation</h2>
<blockquote>
<p>For each service, Istio applies the narrowest matching policy. The order is: service-specific &gt; namespace-wide &gt; mesh-wide. If more than one service-specific policy matches a service, Istio selects one of them at random. Operators must avoid such conflicts when configuring their policies.</p>
<p>To enforce uniqueness for mesh-wide and namespace-wide policies, Istio accepts only one authentication policy per mesh and one authentication policy per namespace. Istio also requires mesh-wide and namespace-wide policies to have the specific name default.</p>
<p>If a service has no matching policies, both transport authentication and origin authentication are disabled.</p>
</blockquote>
