這邊主要是在公司的項(xiàng)目中遇到的問(wèn)題和一般簡(jiǎn)單的遇到的哪些問(wèn)題和解決方式！

（ps：也不知道為什么，從剛踏上it的編程之路無(wú)論是大學(xué)的項(xiàng)目設(shè)計(jì)還是職業(yè)生涯的web，java，.net,都會(huì)設(shè)計(jì)到登錄有關(guān)的問(wèn)題，但是就僅僅這個(gè)功能的設(shè)計(jì)，有淺有深，上下限很大，讓我心中一萬(wàn)只草泥馬奔過(guò)）

一 普通登錄

一個(gè)登錄頁(yè)面，輸入賬號(hào)密碼，提交Form表單，后端查詢數(shù)據(jù)庫(kù)對(duì)應(yīng)用戶名的密碼，匹配正確則把用戶記錄到Session，不正確則返回錯(cuò)誤。這種登錄，在上學(xué)的時(shí)候，也許敬愛(ài)的老師就已經(jīng)教過(guò)你了。但可能他沒(méi)有教你的是，密碼需要hash加密，session為什么可以記錄登錄用戶的原理。

密碼hash： 就是存進(jìn)數(shù)據(jù)庫(kù)中的是一串密文，不是明文，加密的過(guò)程是不可逆轉(zhuǎn)的！

在這之前還是需要理解一個(gè)概念：那就是session。

那什么是session呢？它的原理是什么樣的？它的原理大概是醬紫的：服務(wù)器端維護(hù)一個(gè)session的表，這個(gè)表的每一條記錄存的就是與某一個(gè)客戶端的會(huì)話，會(huì)話會(huì)有過(guò)期時(shí)間，過(guò)期的會(huì)話會(huì)被清理。然后這個(gè)會(huì)話，會(huì)有一個(gè)對(duì)應(yīng)的id，一般是一串長(zhǎng)長(zhǎng)的看不懂的字符串，然后這個(gè)字符串會(huì)被存儲(chǔ)在客戶端的cookie中，每一次請(qǐng)求服務(wù)器端都會(huì)帶上這個(gè)cookie，服務(wù)器端就知道訪問(wèn)的就是哪個(gè)客戶端了。

二 獨(dú)立系統(tǒng)的登錄

這個(gè)一般是后臺(tái)的登錄方式： 一個(gè)域名是www.site.com，一個(gè)則是passport.site.com了。要在不同的域名下進(jìn)行登錄，一般的方法是www.site.com/login跳轉(zhuǎn)到passport.site.com/login，passport這邊是一個(gè)登錄頁(yè)面，用戶輸入賬號(hào)密碼登錄成功之后，passport會(huì)通過(guò)帶著一個(gè)可逆加密的包含用戶信息的token，重定向到www.site.com提供的回調(diào)處理地址，然后進(jìn)行解密，匹配正確，則登錄用戶。要注意的是，這里的加密的信息需要包含一個(gè)時(shí)間戳，接收方需要認(rèn)證這個(gè)時(shí)間戳，過(guò)期登錄失敗。避免token被竊取，被無(wú)限登錄site系統(tǒng)。

三 ?單點(diǎn)登錄

單點(diǎn)登錄需要實(shí)現(xiàn)的需求，說(shuō)白了就是在站點(diǎn)A的登錄了，那么用戶就自動(dòng)在站點(diǎn)B、站點(diǎn)C、站點(diǎn)E、F、G登錄。

這又分兩種情況，A站點(diǎn)和B站點(diǎn)是否在同一個(gè)二級(jí)域名下。

假如是在同一個(gè)域名下，例如siteA.site.com與siteB.site.com，因?yàn)閏ookie允許設(shè)置到二級(jí)域名下.site.com，所以siteA和siteB是可以共享cookie的，用戶的信息可以通過(guò)可逆加密放在二級(jí)域名下的cookie，并且設(shè)置http only，就可以一站登錄，站站登錄。

而如果A站點(diǎn)和B站點(diǎn)不在同一二級(jí)域名下，例如www.siteA.com與www.siteB.com，他們就無(wú)法通過(guò)共享cookie的方式共享用戶信息，所以需要用到j(luò)sonp的方式，用戶在siteA登錄之后，提供一個(gè)jsonp接口獲取加密的用戶信息，siteB訪問(wèn)這個(gè)jsonp獲取加密信息。達(dá)到共享用戶狀態(tài)的效果。

其實(shí)還有一種方式：重定向的方式

四 OAuth2.0登錄

第三方登錄都是實(shí)現(xiàn)了OAuth2.0協(xié)議的，流程大概是醬紫的：

第三方提供一個(gè)登錄入口，也就是第三方域名下的登錄頁(yè)面。主站需要登錄的時(shí)候，引導(dǎo)用戶重定向到第三方的登錄頁(yè)面，用戶輸入賬號(hào)密碼之后，登錄第三方系統(tǒng)，第三方系統(tǒng)匹配帳號(hào)成功之后，帶上一個(gè)code到主站的回調(diào)地址，主站接收到code，短時(shí)間內(nèi)拿著code請(qǐng)求第三方提供獲取長(zhǎng)期憑證的接口(因?yàn)閏ode有一個(gè)比較短的過(guò)期時(shí)間)，這個(gè)長(zhǎng)期憑證叫access_token，獲取之后就把這個(gè)access_token存到數(shù)據(jù)庫(kù)中，請(qǐng)求一些第三方提供的API，需要用到這個(gè)access_token，因?yàn)檫@個(gè)token就是記錄用戶在第三方系統(tǒng)的一個(gè)身份憑證。一些系統(tǒng)，在獲取access_token的時(shí)候，還會(huì)返回一個(gè)副參數(shù)refresh_token，因?yàn)閍ccess_token是有過(guò)期時(shí)間的，一旦過(guò)期了，主站可以使用refresh_token請(qǐng)求第三方提供的接口獲取新的access_token以及新的refresh_token。

這里講一下授權(quán)的思路：

1 ?客戶端向資源所有者發(fā)送授權(quán)請(qǐng)求，客戶端的身份信息，請(qǐng)求資源路徑，對(duì)數(shù)據(jù)的操作方法

2 資源所有者批準(zhǔn)授權(quán)，發(fā)送給客戶端，不批準(zhǔn)就拒絕授權(quán)信息

3 客戶端向授權(quán)服務(wù)器發(fā)送授權(quán)認(rèn)證

4 確認(rèn)認(rèn)證后，發(fā)送accesstoken

5 客戶端在accesstoken有效期間向資源所有者請(qǐng)求有效資源

6 確定accesstoken 有效性和真實(shí)性后，提供相應(yīng)的操作

以下是我自己在xmind中畫的大致理解：

未完待續(xù)！?。。。。。。。。。。。。。。。。。。。?/div>