X-Userinfo header not passed upstream after introspection

[bhedia]

I'm using the introspection endpoint to verify the access token (Bearer) passed into Kong from a client side application, and I was expecting the X-Userinfo header to be added to the upstream request after introspection.

But looking at this code here (and my own testing), I don't see that happening.

function handle(oidcConfig)
  local response
  if oidcConfig.introspection_endpoint then
    response = introspect(oidcConfig)
    if response then
      utils.injectUser(response)
    end
  end

  if response == nil then
    response = make_oidc(oidcConfig)
    if response and response.user then
      utils.injectUser(response.user)
      ngx.req.set_header("X-Userinfo", cjson.encode(response.user))
    end
  end
end

I'm not sure why the header is added in the second path (full oidc) but not added after introspection.

I'd like to pass the user info to the upstream server, to set the context for execution. Ideally, I'd like to secure that by passing down the id_token instead, but I don't know how to do that.

[Trojan295]

The X-Userinfo header should contain the claims of the ID token, but the introspection supports also other JWT, like an access token. I'm not sure, if putting blindly the claims of any token to the X-Userinfo header is right.

@phirvone , @pag-r, what do you think?

[raelmax]

Any update about this question? I think that the expected behavior is have a X-Userinfo after introspection, because the upstream service shouldn't be aware of how the auth process occur.

[vl4d]

I was wondering about this as well, the upstream service shouldn't care much about the auth process just that a valid user made it through.

I had to create a follow up plugin that when coupled with this one, checked for a given field as the username in X-Userinfo and then created a consumer (if wanted) based on that field being present or not and passes that consumer to the upstream in the expected kong headers of x-consumer-username, x-consumer-id

See plugin here kong-oidc-consumer. -based on kong 0.14.1-

I was wondering if I should send a PR to add it to this plugin, but I think its a diff concern. But now with a created consumer, you should be able to rate-limit the consumer among other things kong has available specific to consumers like acls etc.