用戶認證指在用戶訪問服務的時候確認用戶的身份，受限於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-borsos