How to retrieve JWT token in HTTP header with keycloak gatekeeper

Getting advice
1

Hello,
How to retrieve JWT token in HTTP header with keycloak gatekeeper? Currently , after I login into app through keycloak/keycloak gatekeeper I can see only a cookie in browser

Thanks,
Alex

2

There is config option --enable-token-header: enables the token authentication header X-Auth-Token to upstream (default: true) -> so your app (upstream endpoint) will see it in the X-Auth-Token request header.

3

Thanks @jangaraj
Is it really enabled by default? because I see only received cookie after authentication through keycloak gatekeeper

Checked as reference https://github.com/keycloak/keycloak-documentation/blob/master/securing_apps/topics/oidc/keycloak-gatekeeper.adoc

4

What exactly are you expecting? Do you want to see JWT token in the response header in the user browser? That is not right. It is visible as request header in the upstream app. I guess you have wrong expectation.

5

@jangaraj
That clarifies, do you have an easy idea how to view received token by uptream app? Probably some example app docker image with proper logging. I’d like to test as real user case as possible, so browser is preferred than curl

Update: checking with this image https://github.com/mendhak/docker-http-https-echo

6

Here is the response from upstream app from pod log which is accessible via keycloak gatekeeper.
There are no X-Auth-Token related entries in upstream pod with docker image: mendhak/http-https-echo (should log all http calls)

"x-forwarded-port": "8080" is keycloak gatekeeper port

@jangaraj , please suggest

Update: checked tcpdump logs for upstream container and still there is no reference for tokens

{
  "path": "/admin",
  "headers": {
    "cache-control": "max-age=0",
    "keycloak_username": "user",
    "x-b3-traceid": "4d17e13e869c503de1ef81d00eb7e6bb",
    "accept-encoding": "gzip, deflate, br",
    "x-request-id": "ab271fae-d521-9194-a117-6977cfed5e17",
    "sec-fetch-user": "?1",
    "x-envoy-internal": "true",
    "x-istio-attributes": "XXX...Yy5jbHVzdGVyLmxvY2FsCkYKF2Rlc3RpbmF0aW9uLnNlcnZpY2UudWlkEisSKWlzdGlvOi8vZGVtby9zZXJ2aWNlcy9rZXljbG9hay1wcm94eS1kZW1v",
    "sec-fetch-site": "same-site",
    "x-forwarded-port": "8080",
    "x-b3-spanid": "e1ef81d00eb7e6bb",
    "x-forwarded-for": "172.30.182.147",
    "cookie": "keycloak.demo.session=dwQPH-7R13nXzRG2pwf3CraxW1XoxVaKCAXEWwdJ",
    "referer": "https://keycloakdemo.example.com/auth/realms/demo/login-actions/authenticate?client_id=demo&tab_id=rP7JC92Ptv8",
    "host": "demo2.example.com",
    "x-forwarded-host": "demo2.example.com",
    "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3",
    "accept-language": "en-US,en;q=0.9",
    "sec-fetch-mode": "navigate",
    "x-forwarded-server": "demo2.example.com",
    "keycloak_email": "user@user.com",
    "user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36",
    "x-b3-sampled": "1",
    "keycloak_subject": "17621b18-cc91-4232-99d5-75905a362d74",
    "x-forwarded-proto": "https",
    "x-envoy-decorator-operation": "keycloak-proxy-demo.demo.svc.cluster.local:80/*",
    "content-length": "0",
    "upgrade-insecure-requests": "1"
  },
  "method": "GET",
  "body": "",
  "fresh": false,
  "hostname": "demo2.example.com",
  "ip": "::ffff:172.30.59.153",
  "ips": [],
  "protocol": "http",
  "query": {
    "session_state": "bd2682ac-6d6f-40fb-b270-a3bd45a02074"
  },
  "subdomains": [
    "dev",
    "isabel",
    "demo2"
  ],
  "xhr": false,
  "os": {
    "hostname": "demo-574cc69774-sfj9w"
  }
}
7

You have whole orchestration (I guess k8s + istio) which may modify headers. Start with containers on your localhost to prove it first and then configure your infrastructure properly.

8

Thank you for support @jangaraj
Switching to newer 7 version for both keycloak and keycloak-gatekeeper and set parameter - enable-authorization-header=true solved the issue