Description

I'd like to extend jwt-auth plugin to store the authenticated JWT in the request context, so that it can easily be used in a plugin which executes after (lower priority), such as a custom ACL based on JWT payload.

Benefits

These are the benefits that come to my mind:

• hiding the token from headers - this allows to enable hide_credentials and hide the JWT from the server receiving the request, but still allows subsequent plugins to access it;
• less redundant code - the following plugins do not have to import extra modules to parse again the token, but can simply access its claims as a table.

Example

Suppose the jwt-auth plugin stores the decoded jwt object in request context (jwt-auth.lua):

function _M.rewrite(conf, ctx)
    -- [...]

    ctx.jwt_obj = jwt_obj
end

Custom plugin example (my-acl.lua):

function _M.rewrite(conf, ctx)
    -- [...]

    if not ctx.jwt_obj then
        -- Technically this can only happen when the JWT plugin didn't run for this request, or the priority was lower
        core.log.warn("Token object not found in ctx.")
        return 401, {message = "Missing JWT in request"}
    end

    local authorized = false
    local roles = ctx.jwt_obj.payload.roles

    -- Do something with roles
    for i, value in ipairs(tab) do
        if value == "admin" then
            authorized = true
        end
    end

    if not authorized then
        core.log.warn("Request not authorized")
        return 403, {message = "You are not allowed to access this resource"}
    end

    -- [...]
end

Additional Information

Kong JWT Plugin stores the encoded token in context, which I find interesting but a little bit unhandy: https://github.com/Kong/kong/blob/d4ab528fa2414d996861a43e58406c02b4978157/kong/plugins/jwt/handler.lua#L146