這個問題我記得是我幾年前一位面試官問過我的一個問題，當時技術還不夠自信，有點懵。那麼Java中具體有哪幾種登入方法的實現呢？

基本上就是您說的這兩種：第一種簡單的查詢使用者名稱密碼並返回與資料庫對比實現登入，這種事比較常見的登入方法的實現。第二種就是SSO（單點登入），只要登入一個系統就可以實現多個子系統無需再次輸入密碼直接登入實現的方法。

目前就是比較多的就是這兩種，但是具體選擇還是要根據實際應用場景去做。

Java開發中隨不同應用，有各種不同的登陸方法：

1、最簡單的，透過使用者和密碼登入。

2、如果在企業B端系統，使用者需要登入很多個系統，每個系統都有每個系統的使用者名稱和密碼，他們很難記住，即使設定成相同的使用者名稱和密碼，但需要改密碼的時候，每個系統都要修改，十分麻煩，這時，就需要實現單點登入。

3、如果在多租戶系統中，如OFBIZ多租戶系統,是從OFBIZ的單一副本執行的單獨的資料例項的能力。每個資料例項儲存在制定給租戶的一個單獨的資料庫中。使用者透過登入表單的形式制定租戶ID登入到一個數據實例。必須進行多種配置才能使用OFBIZ多租戶。這時，登陸不僅需要使用者和密碼，而且還需要TenantId，見下圖

4、如果需要更加安全的登陸，比如各個銀行的網銀系統，稅務的報稅系統，需要使用者本地安裝有效地數字證書才能登陸。

5、區塊鏈登陸，本質上也是採用數字證書的方式登陸。比如區塊鏈錢包，需要澄清的是，區塊鏈領域提到的錢包其實並不是裝錢的錢包，而是裝金鑰（私鑰和公鑰）的工具，有了金鑰就可以擁有相應地址上的數字貨幣的支配權。私鑰：是對一個比特幣地址擁有取錢許可權的代表，掌握了私鑰就掌握了其對應比特幣地址上的所有生殺大權。私鑰可以算出公鑰，公鑰可以再算出比特幣地址。每次交易的時候，付款方必須出具私鑰，以及私鑰產生的簽名，每次交易簽名不同，但是由同一個私鑰產生。私鑰是一串。公鑰：是和私鑰成對出現的，公鑰可以算出比特幣地址，因此可以作為擁有這個比特幣地址的憑證。比特幣地址：如果說區塊鏈是一個賬本，比特幣地址就是其中的賬號。如果我們把比特幣錢包簡單比作成銀行卡賬戶的話，那麼比特幣錢包地址就可以看成是銀行卡賬號。不同的是，比特幣地址是可以不儲存在網路上的，更是可以獨立於你的錢包而存在的。

總之，根據不同的要求，可以採用不同的機制實現系統的登陸。

還可以開發來支援一個使用者多裝置登入。大體思路就是，系統使用token做使用者憑證的情況下午，使用者登入以後，登入資訊存在快取中，在後臺可以管理，比如可以進行強制下線、踢出裝置等操作。

Java中的鑑權認證框架也不少：shiro、spring security、oauth等。

登入認證幾乎是任何一個系統的標配，web 系統、APP、PC 客戶端等，好多都需要註冊、登入、授權認證。場景說明

以一個電商系統，假設淘寶為例，如果我們想要下單，首先需要註冊一個賬號。擁有了賬號之後，我們需要輸入使用者名稱（比如手機號或郵箱）、密碼完成登入過程。之後如果你在一段時間內再次進入系統，是不需要輸入使用者名稱和密碼的，只有在連續長時間不登入的情況下（例如一個月沒登入過）訪問系統，再次需要輸入使用者名稱和密碼。如果使用頻率很頻繁，通常是一年都不用再輸一次密碼，所以經常在換了一臺電腦或者一部手機之後，一些經常使用的網站或 APP 不記得密碼了。

提煉出來整個過程大概就是如下幾步：

首次使用，需要透過郵箱或手機號註冊；註冊完成後，需要提供使用者名稱和密碼完成登入；下次再使用，通常不會再次輸入使用者名稱和密碼即可直接進入系統並使用其功能（除非連續長時間未使用）；常用的認證方式

OAuth 認證

這一樣一來，即省了使用者註冊的時間，又簡化了你的系統的賬號體系。從而既可以提高使用者註冊率可以節省開發時間，同時，安全性也有了保障。

維基百科對它的解釋摘要如下：

OAuth允許使用者提供一個令牌，而不是使用者名稱和密碼來訪問他們存放在特定服務提供者的資料。每一個令牌授權一個特定的網站（例如，影片編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相簿中的影片）。這樣，OAuth讓使用者可以授權第三方網站訪問他們儲存在另外服務提供者的某些特定資訊，而非所有內容。

假設我們開發了一個電商平臺，並集成了微信登入，以這個場景為例，說一下 OAuth 的工作原理。

講之前需要了解其中涉及到的幾個角色：

使用者：即使用我們平臺的使用者使用者終端：即終端使用者使用的 APP 端或 web 端應用伺服器端：即我們的伺服器端授權伺服器端：這裡就是微信處理授權請求的伺服器

好的，接下來開始在我們的電商平臺web端實現微信登入功能。微信網頁授權是授權碼模式（authorization code）的 OAuth 授權模式。

我們電商平臺的使用者過來登入，常用場景是點選“微信登入”按鈕；接下來，使用者終端將使用者引導到微信授權頁面；使用者同意授權，應用伺服器重定向到之前設定好的 redirect_uri （應用伺服器所在的地址），並附帶上授權碼（code）;應用伺服器用上一步獲取的 code 向微信授權伺服器傳送請求，獲取 access_token，也就是上面說的令牌；之後應用伺服器用上一步獲取的 access_token 去請求微信授權伺服器獲取使用者的基本資訊，例如頭像、暱稱等；

Cookie-Session 認證

早期網際網路以 web 為主，客戶端是瀏覽器，所以 Cookie-Session 方式最那時候最常用的方式，直到現在，一些 web 網站依然用這種方式做認證。

認證過程大致如下：

使用者輸入使用者名稱、密碼或者用簡訊驗證碼方式登入系統；服務端驗證後，建立一個 Session 資訊，並且將 SessionID 存到 cookie，傳送回瀏覽器；下次客戶端再發起請求，自動帶上 cookie 資訊，服務端透過 cookie 獲取 Session 資訊進行校驗；

弊端

只能在 web 場景下使用，如果是 APP 中，不能使用 cookie 的情況下就不能用了；即使能在 web 場景下使用，也要考慮跨域問題，因為 cookie 不能跨域；cookie 存在 CSRF（跨站請求偽造）的風險；如果是分散式服務，需要考慮 Session 同步問題；

Cookie-Session 改造版

由於傳統的 Cookie-Session 認證存在諸多問題，可以把上面的方案改造一下。改動的地方如下：

不用 cookie 做客戶端儲存，改用其他方式，web 下使用 local storage，APP 中使用客戶端資料庫，這樣就實現了跨域，並且避免了 CSRF ;服務端也不存 Session 了，把 Session 資訊拿出來存到 Redis 等記憶體資料庫中，這樣即提高了速度，又避免了 Session 同步問題；

經過改造之後變成了如下的認證過程：

使用者輸入使用者名稱、密碼或者用簡訊驗證碼方式登入系統；服務端經過驗證，將認證資訊構造好的資料結構儲存到 Redis 中，並將 key 值返回給客戶端；客戶端拿到返回的 key，儲存到 local storage 或本地資料庫；下次客戶端再次請求，把 key 值附加到 header 或者 請求體中；服務端根據獲取的 key，到 Redis 中獲取認證資訊；

基於JWT的Token認證

上面的方案雖然經過了改版，但還是需要客戶端和伺服器端維持一個狀態資訊，比如用 cookie 換 session ,或者用 key 換 Redis 的 value 資訊，基於 JWT 的 Token 認證方案可以省去這個過程。

JSON Web Token（JWT）是一個非常輕巧的規範。這個規範允許我們使用JWT在使用者和伺服器之間傳遞安全可靠的資訊。

認證過程

依然是使用者登入系統；服務端驗證，將認證資訊透過指定的演算法（例如HS256）進行加密，例如對使用者名稱和使用者所屬角色進行加密，加密私鑰是儲存在伺服器端的，將加密後的結果傳送給客戶端，加密的字串格式為三個"." 分隔的字串 Token，分別對應頭部、載荷與簽名，頭部和載荷都可以透過 base64 解碼出來，簽名部分不可以；客戶端拿到返回的 Token，儲存到 local storage 或本地資料庫；下次客戶端再次發起請求，將 Token 附加到 header 中；服務端獲取 header 中的 Token ，透過相同的演算法對 Token 中的使用者名稱和所屬角色進行相同的加密驗證，如果驗證結果相同，則說明這個請求是正常的，沒有被篡改。這個過程可以完全不涉及到查詢 Redis 或其他儲存；

優點

使用 json 作為資料傳輸，有廣泛的通用型，並且體積小，便於傳輸；不需要在伺服器端儲存相關資訊；jwt 載荷部分可以儲存業務相關的資訊（非敏感的），例如使用者資訊、角色等；總結

綜上所述，JWT 可以作為首選的認證方案。當然，具體的情況具體分析，還要看是不是適合真實的應用場景。除了上述的這些，涉及到資訊保安的，建議全部採用 https 方式部署，採用 https 方式，資訊很難被嗅探破解，對應用的安全性很重要。