使用者認證指在使用者訪問服務的時候確認使用者的身份，受限於HTTP無狀態的特性，應用開發者需要自行實現使用者認證相關功能。

通常是使用者登入時服務端生成通行證返回給客戶端，客戶端在接下來的請求中攜帶通行證，然後服務端通過校驗該通行證實現使用者認證。

不管具體的業務是什麼，如果使用者認證失敗，那麼所有的後續操作都無法執行，需要返回給客戶端使用者認證失敗，對應到HTTP Status Code是401。

本文闡述隨著流量和規模增長，服務從單機應用發展到微服務架構的過程中，使用者認證功能的實現方式變遷。

單機應用

這個階段只有一臺伺服器，應用將session維護在本機的記憶體/磁碟，然後生成一個session id告之客戶端即可。很多Web框架有內建的實現，開箱即用，有時間簡單到你都沒注意到使用者認證的存在。

但是一臺應用伺服器往往不夠用，有多個理由：流量太大一臺扛不住、機器一掛服務就掛可用性太低...

負載均衡

因為有多臺伺服器，所以沒法再簡單地將session維護在本機上，因為使用者在一臺機器上登入後，下次訪問可能就到了另一臺機器。

• 方案A：認證令牌

在登入的時候將一些使用者的資訊編碼到一個字串裡返回給客戶端，客戶端在隨後的操作中攜帶此字串操作，服務端驗證這個字串，字串合法則認證通過並從字串中讀取使用者身份資訊。

這樣就不需要服務端再儲存session資訊，輕鬆支援多臺伺服器。而這個用來認證的字串，就跟軍隊的通關令牌一樣，我們管它叫認證令牌。

認證令牌的格式需要仔細設計，要能防篡改、具備有效期、要能放到URL中使用、還要可擴充套件等等。已經有人設計了好了一種令牌格式，還形成了標準叫JWT，可以直接拿來用，當然要是嫌JWT不好用，重新設計一個也是可以的。

這裡有一份JWT的簡明介紹。

認證令牌這個方案的缺點是，難以實現登入態的雲端管理。通常一個令牌生成後，只能等它過期或者encode在其中的某些使用者身份資訊發生變化的時候才會生效。像使用者退登就失效、使用者的線上裝置管理、使用者的登入態管控等功能，沒有辦法實現。

• 方案B：分散式Session

還有一種方案，將session從應用伺服器拿出來單獨維護，形成一個分散式session，這樣每一臺應用伺服器都能訪問得到。

具體到實現，分散式Session可以是Redis、MySQL等。但不管用什麼樣的儲存系統，使用者認證服務的可用性都強依賴它，相比認證令牌不需要服務端儲存的方案，可用性肯定相對要低一些。

• 方案A+B

認證令牌有功能缺失，分散式Session可用性相對不足，把兩者結合起來就成了順利成章的方案。

將認證令牌當做session id，正常服務時，使用者認證都做分散式session校驗，而當分散式session依賴的儲存系統偶爾出現故障時，則服務降級，改為只校驗認證令牌。這樣可用性有保障，功能也齊全。

如果需要保證登入服務時，分散式Session也是高可用的，還可以在令牌裡面增加一個欄位用來區分有session和無session的型別。

微服務

業務規模越來越大，團隊人數越來越多。一起維護同一個服務越來越難了，需要服務拆分，但不管怎麼拆，使用者認證是每個面向終端使用者的服務都需要的。

使用者認證都需要，只要在拆分的時候把相關程式碼都拷貝走，然後各個服務都要依賴使用者資訊和分散式session。

這樣維護起來困難太大，只好將使用者認證相關的功能拆分出來，形成一個獨立的使用者認證服務。這個服務幾乎每一個大點的網際網路公司都有，名字不太一樣，有的叫Passport，有的叫Account，有的叫User，但總歸功能是差不多的。

這樣登入、註冊、使用者認證相關的程式碼、資料、線上部署，完全獨立出來，形成一個使用者認證服務。然後隨著業務增長，服務會繼續拆分，越來越多。服務之間可能有依賴，然後大部分服務尤其是面向終端使用者的服務都會依賴使用者認證服務。

依賴使用者認證服務的獨立微服務越來越多，重複的對接工作需要進行很多次，另外在使用者的一次請求中往往涉及多個微服務，在各個微服務單獨對接使用者認證的情況下，難免會進行多次使用者認證，造成重複請求，資源浪費。

API閘道器

通過外網API閘道器，將公司所有的對外介面的簽名和使用者身份認證收攏到一起。API閘道器收到使用者的認證令牌之後，先去使用者認證服務換取使用者id，然後使用使用者id訪問其它微服務。這樣各個微服務都根據使用者uid提供服務，不再需要關心終端使用者的身份認證，而使用者認證服務也只需要對接API閘道器即可，各自的工作量都大大減小。

Reference

https://www.slideshare.net/opencredo/authentication-in-microservice-systems-david-bor