X-Auth-UserId header should be cleared before attempting authentication

[hkarim]

Should note in the documentation or the examples that it is safer to clear the X-Auth-UserId header before trying to authenticate the request, something like:

location /secure {
      access_by_lua '
        ngx.req.clear_header("X-Auth-UserId") 
        local jwt = require("nginx-jwt")
        jwt.auth()
      ';
}

Also noticed that the header is being set on the response not the request, shouldn't it be the other way around? So that backends get the authenticated subject. Currently, we have this in our nginx-jwt.lua:

-- write the X-Auth-UserId header
-- ngx.header["X-Auth-UserId"] = jwt_obj.payload.sub
ngx.req.set_header("X-Auth-UserId", jwt_obj.payload.sub)

[twistedstream]

@hkarim: The X-Auth-UserId response header emitted by the nginx-jwt script is not really intended to be consumed by the backing service. Per the docs (end of the Usage section) it's really just a convenience feature so you can see the ID of the user who authenticated in the response. If you're concerned about this being a security issue, perhaps we can make the rendering of this field optional.

One of the primary use cases of the nginx-jwt script is to provide a security layer for existing backends that can't be modified, or at least not very easily. Nginx makes it easy to layer something like this on. However, I think there is also a class of use cases where the backend could make use of some data being passed in. It sounds like you're in that camp where you have a backend that can be modified such that claims within the JWT can passed to it. I think you're approach of passing additional request headers to the backing service is very appropriate in this case, especially if that's what your backend can consume. Not everyone using this library has that luxury.

Finally, regarding your opening question about clearing the X-Auth-UserId on its way to the backing service. For the reasons I've given, unless your backend is expecting this header to be sent, this shouldn't be an issue. It certainly shouldn't effect the header being written back out on the response to the external caller.

[roryrjb]

@hkarim +1 for adding X-Auth-UserId for the backend, I have this exact line in my version of nginx-jwt:

ngx.req.set_header("X-Auth-UserId", jwt_obj.payload.sub)

@twistedstream I was writing a PR for this then noticed @platinummonkey mentioned in #46 that he already has a PR lined up for this exact fix, he's just waiting for his previous PR to be merged.

[platinummonkey]

I'm not sure what's going on over at auth0 preventing responsiveness, but I decided to fork nginx-jwt over here: https://github.com/platinummonkey/nginx-jwt I'm currently merging in a number of these issue fixes, and will be setting up CI as well.

[andrewzk]

+1 to both of @hkarim's points

[tarachandverma]

You can use this module - https://github.com/tarachandverma/nginx-openidc which clears the header before authentication.