Kong gracefully realizes micro service gateway authentication and landing the login scenario in the actual combat chapter

catalogue

  • Login implementation
    • After B-terminal logs in, the browser saves cookie s
    • Login code implementation details, cookie design
  • Gateway introduction
    • What is the API gateway
    • Why do I need a gateway
    • From a technical point of view, what is Kong?
    • Why use Kong
  • Kong gateway resolves cookie s
    • kong project profile, traffic forwarding
    • Authentication lua script
    • Service resolution request
  • Advantages and disadvantages of this scheme
    • Single sign on problem
    • Login renewal problem
    • Logout issue

Login implementation

After B-terminal logs in, the browser saves cookie s

Composition of Kong project

This project only performs authentication and belongs to the intranet gateway. Before that, the traffic will pass through an external gateway. There are functions such as flow control, request distribution and certificate configuration. The intranet gateway only performs authentication. After the traffic reaches here for authentication, different routes will be forwarded to different services in k8s to call specific services.

The project deploys two environments: Online gateway and test environment gateway. The plugins plug-in authentication provided includes APP end authentication, C end authentication and B end authentication. Here I mainly talk about B end authentication, and others are briefly introduced:

  • Shop resolve is mainly used for store information authentication in applet and H5 environments, which is needed for an e-commerce project of the company;
  • Idk client type resolve is mainly used for access authentication in applet and H5 environments;
  • There's nothing to say about health check. It's necessary for k8s's health check
  • The other three app resolve, Buser resolve and customer resolve are the authentication of the app environment, B-side and C-side respectively

B-side authentication lua script

local ngx_re = require "ngx.re"
local BasePlugin = require "kong.plugins.base_plugin"
local string = require "resty.string"
local BuserResolveHandler = BasePlugin:extend()

function BuserResolveHandler:new()
    BuserResolveHandler.super.new(self, "buser-resolve")
end

function BuserResolveHandler:access(conf)
    BuserResolveHandler.super.access(self)
    local cookieName = "cookie_" .. "KUAIZHAN_V2"
    local kuaizhanV2 = ngx.var[cookieName]
--     ngx.log(ngx.ERR, "kuaizhanV2", kuaizhanV2)
    local uid = 0
    ngx.req.set_header("X-User-Id", uid)
  
    // cookie content 3001459%7C1636684996%7C7180720502%7Cb61a12ef865072964aa359e6a9ef2e0b1846dee9
    if xxx_V2 and xxx_V2 ~= '' then
        local res, err = ngx_re.split(xxxV2, "%7C")
        if err then
            return
        end
        // userId, time, nonce, sign are obtained by parsing,
        // They are 300145916366849967180720502, b61a12ef865072964aa359e6a9ef2e0b1846dee9 respectively
        local userId, time, nonce, sign = res[1], res[2], res[3], res[4]
        // According to the key, time, signature, using hmac_sha1 algorithm, hexadecimal algorithm, get the summary signature
        local digest = ngx.hmac_sha1(conf.secret, userId .. time .. nonce)
        local theSign = string.to_hex(digest)
        -- TODO Plus expiration time judgment
        // Calculate whether the signature and cookie parsing result in the same sign, and assign uid if they are the same
        if theSign == sign then
            uid = userId
        end
        ngx.log(ngx.ERR, "theSign:", theSign, "sign:", sign, "uid:", uid)
    end

    ngx.log(ngx.ERR, "get x-user-id:" .. uid)
    // The X-User-Id is stored in the nginx request header, and then forwarded to each business line
    ngx.req.set_header("X-User-Id", uid)
end

return BuserResolveHandler

However, single sign on cannot be done in the case of multiple terminals or cross top domains.

Login renewal problem

I wonder if you have noticed that there is an expiration time behind the first cookie screenshot. Due to the dependence on cookies, they will be kicked off the line as long as they expire and need to log in again, which will affect the customer experience to a certain extent.

Many applications now use the token + redis scheme to realize login renewal. For example, if you have logged in for ten consecutive days, you don't need to log in again. The back end realizes automatic renewal. Only those who haven't logged in for more than ten days fail and need to log in again.

However, the cost of redis is required to renew the service, which saves the cost.

Logout issue

The cancellation of this scheme is simply to delete the cookie. If a person with a heart gets the cookie, it can still be used, and the cookie will not expire within the validity period.

The token+redis scheme can make the real token invalid.

Posted on Thu, 02 Dec 2021 20:46:15 -0500 by simonp