這邊主要是在公司的專案中遇到的問題和一般簡單的遇到的哪些問題和解決方式！
（ps：也不知道為什麼，從剛踏上it的程式設計之路無論是大學的專案設計還是職業生涯的web，java，.net,都會設計到登入有關的問題，但是就僅僅這個功能的設計，有淺有深，上下限很大，讓我心中一萬隻草泥馬奔過）
一 普通登入
一個登入頁面，輸入賬號密碼，提交Form表單，後端查詢資料庫對應使用者名稱的密碼，匹配正確則把使用者記錄到Session，不正確則返回錯誤。這種登入，在上學的時候，也許敬愛的老師就已經教過你了。但可能他沒有教你的是，密碼需要hash加密，session為什麼可以記錄登入使用者的原理。
密碼hash： 就是存進資料庫中的是一串密文，不是明文，加密的過程是不可逆轉的！
在這之前還是需要理解一個概念：那就是session。
那什麼是session呢？它的原理是什麼樣的？它的原理大概是醬紫的：伺服器端維護一個session的表，這個表的每一條記錄存的就是與某一個客戶端的會話，會話會有過期時間，過期的會話會被清理。然後這個會話，會有一個對應的id，一般是一串長長的看不懂的字串，然後這個字串會被儲存在客戶端的cookie中，每一次請求伺服器端都會帶上這個cookie，伺服器端就知道訪問的就是哪個客戶端了。
二 獨立系統的登入
這個一般是後臺的登入方式： 一個域名是www.site.com，一個則是passport.site.com了。要在不同的域名下進行登入，一般的方法是www.site.com/login跳轉到passport.site.com/login，passport這邊是一個登入頁面，使用者輸入賬號密碼登入成功之後，passport會通過帶著一個可逆加密的包含使用者資訊的token，重定向到www.site.com提供的回撥處理地址，然後進行解密，匹配正確，則登入使用者。要注意的是，這裡的加密的資訊需要包含一個時間戳，接收方需要認證這個時間戳，過期登入失敗。避免token被竊取，被無限登入site系統。
三 單點登入
單點登入需要實現的需求，說白了就是在站點A的登入了，那麼使用者就自動在站點B、站點C、站點E、F、G登入。
這又分兩種情況，A站點和B站點是否在同一個二級域名下。
假如是在同一個域名下，例如siteA.site.com與siteB.site.com，因為cookie允許設定到二級域名下.site.com，所以siteA和siteB是可以共享cookie的，使用者的資訊可以通過可逆加密放在二級域名下的cookie，並且設定http only，就可以一站登入，站站登入。
而如果A站點和B站點不在同一二級域名下，例如www.siteA.com與www.siteB.com，他們就無法通過共享cookie的方式共享使用者資訊，所以需要用到jsonp的方式，使用者在siteA登入之後，提供一個jsonp介面獲取加密的使用者資訊，siteB訪問這個jsonp獲取加密資訊。達到共享使用者狀態的效果。
其實還有一種方式：重定向的方式
四 OAuth2.0登入
第三方登入都是實現了OAuth2.0協議的，流程大概是醬紫的：
第三方提供一個登入入口，也就是第三方域名下的登入頁面。主站需要登入的時候，引導使用者重定向到第三方的登入頁面，使用者輸入賬號密碼之後，登入第三方系統，第三方系統匹配帳號成功之後，帶上一個code到主站的回撥地址，主站接收到code，短時間內拿著code請求第三方提供獲取長期憑證的介面(因為code有一個比較短的過期時間)，這個長期憑證叫access_token，獲取之後就把這個access_token存到資料庫中，請求一些第三方提供的API，需要用到這個access_token，因為這個token就是記錄使用者在第三方系統的一個身份憑證。一些系統，在獲取access_token的時候，還會返回一個副引數refresh_token，因為access_token是有過期時間的，一旦過期了，主站可以使用refresh_token請求第三方提供的介面獲取新的access_token以及新的refresh_token。
這裡講一下授權的思路：
1 客戶端向資源所有者傳送授權請求，客戶端的身份資訊，請求資源路徑，對資料的操作方法
2 資源所有者批准授權，傳送給客戶端，不批准就拒絕授權資訊
3 客戶端向授權伺服器傳送授權認證
4 確認認證後，傳送accesstoken
5 客戶端在accesstoken有效期間向資源所有者請求有效資源
6 確定accesstoken 有效性和真實性後，提供相應的操作
以下是我自己在xmind中畫的大致理解：
