api授權是什么？最近，我在考慮微服務網關的身份驗證和授權，以保護API。我的理解是，當客戶端訪問API時，它將由網關進行身份驗證。如果身份驗證通過，將調用API。否則，將返回403，用戶將輸入密碼和

api授權是什么？

最近，我在考慮微服務網關的身份驗證和授權，以保護API。我的理解是，當客戶端訪問API時，它將由網關進行身份驗證。如果身份驗證通過，將調用API。否則，將返回403，用戶將輸入密碼和帳戶進行身份驗證。但我不明白的是，如果這個網站，比如淘寶網，不用登錄就可以訪問，那么這個API就不用認證客戶端就可以調用了，這和上面對認證和授權的理解是不同的，或者其他API接口的授權和認證意味著別的什么。

企業(yè)級微服務架構下API保護和控制層如何做？

在spring云方面，要實現API的認證和保護，需要與JWT技術（無狀態(tài)）合作。一般有兩種方法：

方法一：

直接在網關中設置各種過濾器，配置一定的路由攔截規(guī)則，將部分用戶認證碼編碼到網關中，實現網關端的初步認證和認證。這意味著超過90%的系統(tǒng)認證是在網關上進行的。所有客戶端都請求網關的地址，而不是微服務的實際地址。當請求通過nginx到達springcloud網關時，網關取出請求的前綴，然后根據代碼中配置的pre、post、error等過濾器選擇相應的過濾器。網關根據請求中攜帶的JWT信息，解析后取出憑證信息，如果用戶中心返回正確結果，則執(zhí)行用戶定義的登錄認證邏輯（一般網關服務調用用戶中心服務進行檢查），網關服務接收響應結果，向篩選器返回NULL，并請求繼續(xù)向其他微服務發(fā)送。執(zhí)行相應的業(yè)務邏輯后，相應的業(yè)務服務將結果返回給網關，網關通過nginx將結果返回給客戶端。

方法二：原理同上，區(qū)別在于一個新的微服務叫做用戶授權認證中心。當請求到來時，網關只做最基本的請求驗證，如JWT格式是否合法，JWT是否過期，不再對用戶進行認證操作，即不在網關中查詢用戶，而是調用用戶授權認證中心，通過必要的參數到中心對應的HTTP方法中，請求后得到結果并返回給網關，然后網關給出客戶端特定的信息，如果認證失敗，將返回給客戶端。如果身份驗證成功，它將在網關篩選器中釋放。這意味著網關的工作要少得多，90%以上的認證操作都在授權認證中心進行。

這兩種方法都可以使用，但建議使用第二種方法，這更符合微服務的理念。第一種適用于項目的初始階段。當規(guī)模不大時，可以暫時使用。當流量出現時，網關將無法承受，因此從長遠來看，需要開通新的微服務來分流流量。