Use Istio for authorisation: how to redirect to login page and how to use JWT cookies


I’m trying to remove user authorization built-in to the applications and move then to istio. In the past i have been able to use RequestAuthentication and AuthorizationPolicy with JWT to secure public restful services. This time its a front-end

We use keycloak OIDC and currently we use lua inside an openresty container to obtain the JWT cookie and based on that the user is either redirected to keycloak’s login page, is granted access or if the user does not have the proper role, we send back a 403 error page.

I have the following questions:

  • How can i have istio/envoy redirect when they need to login?
  • can i use fromHeaders to obtain the JWT from keycloak’s cookies?


I believe i have to add oauth2-proxy in the mix and perhaps use an EnvoyFilter?

Hoping for a simpler solution. Any help is welcome,


As it is related to AuthorizationPolicy, cc @YangminZhu.

  1. you can probably check this blog that tells how to integrate oauth-proxy with istio using EnvoyFilter:, we are also working to provide first-class support for such use cases, see the design doc here

  2. the fromHeaders is used when the JWT token is stored in a different header (the default is Authorization header) in the request. Do you mean you want to verify the JWT token from keycloak stored in some custom header? Also note the request authentication policy doesn’t support opaque cookie, it only supports JWT token.

Thanks for your reply and link!

I was on a similar path, but this helped tremendously. I got to the point where i can login, but my application fails with RBAC: access denied.

I also don’t see any headers in the envoy rbac debug that the envoy proxy can use to authenticate. I do see the cookie', '_oauth2_proxy, but no Authorization header (or X-Forwarded-Access-Token). I did configure oauth2-proxy to pass those:

- '--pass-access-token=true'     #pass token as X-Forwarded-Access-Token
- '--pass-authorization-header=true' # pass OIDC IDToken
- '--set-authorization-header=true'
- '--skip-jwt-bearer-tokens=true' # sets the Authorization Bearer response header
- '--upstream=static://'

But these don’t end up at the app’s envoy proxy. Any ideas?

With --set-xauthrequest=true i am getting the x-auth-request-access-token as a header, but i am not able to set the other headers

For now i’ll use

  - name: x-auth-request-access-token

We now have better support of integrating external authz in Istio 1.9, check the task Istio / External authorization with custom action and the blog Istio / Better External Authorization for more info.

Specifically for oauth2-proxy, you could try with the following configuration:

apiVersion: apps/v1
kind: Deployment
  name: oauth2-proxy
  replicas: 1
      app: oauth2-proxy
        app: oauth2-proxy
      - args:
        - --http-address=
        - --provider=google
        - --email-domain=*
        - --cookie-refresh=1h
        - --cookie-secure=false # Set to false for test environment only
        - --set-xauthrequest # X-Auth-Request-User, X-Auth-Request-Email, X-Auth-Request-Preferred-Username, X-Auth-Request-Groups
        - --pass-access-token # X-Auth-Request-Access-Token, must first enable --set-xauthrequest
        - --set-authorization-header # Authorization: Bearer <JWT>
        - --upstream="static://200"
        - --reverse-proxy
        - name: OAUTH2_PROXY_CLIENT_ID
          value: "<YOUR_CLIENT_ID>"
          value: "<YOUR_CLIENT_SECRET>"
          value: "<YOUR_COOKIE_SECRET>" # could be generated with python -c 'import secrets,base64; print(base64.b64encode(base64.b64encode(secrets.token_bytes(16))));'
        imagePullPolicy: Always
        name: oauth2-proxy
        - containerPort: 4180
          protocol: TCP
apiVersion: v1
kind: Service
  name: oauth2-proxy
    app: oauth2-proxy
  - name: http
    port: 4180
    protocol: TCP
    targetPort: 4180
1 Like

@YangminZhu Similar to external authz, is there a plan to provide first-class support for Envoy oauth2 filter?

Probably in the future but no plans for now, I think the OAuth2 filter API is still in alpha and under active development, we probably need it to be in a more stable stage to have formal support in Istio.