拋磚引玉

在文(wen)章開始(shi)前，先看(kan)看(kan)一個常見(jian)的情況(kuang)????

在集團內(nei)進(jin)行開(kai)發時，通常會遇到不同組之間的(de)合(he)作(zuo)，如(ru)果(guo)(guo)是同一(yi)個組的(de)前后端，因為交互(hu)請(qing)求(qiu)都(dou)是在同一(yi)個「域(yu)」內(nei)發生的(de)，所以(yi)一(yi)般不會存(cun)在跨(kua)域(yu)問題(ti)。但如(ru)果(guo)(guo)未做處理，直接從 a.alibaba.com 請(qing)求(qiu) b.alibaba.com 的(de)接口，就會出現跨(kua)域(yu)的(de)問題(ti)，這是因為瀏覽器對于不同域(yu)請(qing)求(qiu)的(de)限制問題(ti)，其實跨(kua)域(yu)的(de)問題(ti)很好(hao)解，只(zhi)要(yao)設置了正確的(de)請(qing)求(qiu)頭即(ji)可，具體的(de)可以(yi)參考我的(de)這篇(pian)文章 ????《一(yi)次跨(kua)域(yu)問題(ti)的(de)分析》

但這是(shi)訪(fang)問(wen)不(bu)需要(yao)登(deng)錄(lu)的接口，那如(ru)果是(shi)從 a.alibaba.com 訪(fang)問(wen) b.alibaba.com 下的一(yi)個需要(yao)登(deng)錄(lu)的接口呢(ni)？又該如(ru)何解決呢(ni)？

下文以(yi) A 站(zhan)點指代(dai)(dai) a.alibaba.com，B 站(zhan)點指代(dai)(dai) b.alibaba.com

單系統登錄

對于一個 web 應用(yong)(yong)來說，通信協(xie)議通常是(shi) HTTP 協(xie)議，該協(xie)議是(shi)無狀態(tai)的，也(ye)就是(shi)說，在請求(qiu)與請求(qiu)之間是(shi)不(bu)會(hui)產生(sheng)關聯的。這也(ye)就意(yi)味著，任何(he)用(yong)(yong)戶都能(neng)通過(guo)瀏覽器訪問服務(wu)器資源，且不(bu)會(hui)打擾(rao)到其他用(yong)(yong)戶。如下圖所(suo)示 ????

如果想要(yao)保(bao)護某些資源，比如一(yi)(yi)些珍貴(gui)的(de)學(xue)習資料，那就(jiu)必須限制(zhi)瀏覽器(qi)的(de)請求，對(dui)于服務(wu)端來說就(jiu)是(shi)要(yao)知道發出這個請求的(de)人是(shi)誰，也即(ji)讓請求變得有「狀態」，只不過既(ji)然 HTTP 協議無狀態，那就(jiu)讓瀏覽器(qi)和(he)服務(wu)器(qi)之間共(gong)同(tong)維(wei)持(chi)一(yi)(yi)個狀態吧，而這就(jiu)是(shi)最常見的(de)——會話機制(zhi)。

Cookie 和 Session

在會話(hua)(hua)機(ji)制中，最(zui)重要(yao)的就(jiu)是 Cookie 和 Session 了(le)，Session 好理解，服務端(duan)保存(cun)的用來維護某一個用戶的狀態(tai)，瀏覽(lan)器(qi)只需用某種方式(shi)記錄下這個會話(hua)(hua)的 ID 然后之后每(mei)次請(qing)求(qiu)攜(xie)帶即可，想必有(you)小(xiao)伙伴(ban)會發出(chu)疑問了(le)，既(ji)然是給瀏覽(lan)器(qi)攜(xie)帶參數，那么直接(jie)在請(qing)求(qiu)參數里攜(xie)帶不是最(zui)簡(jian)單的嗎？

的確，將會(hui)話(hua) id 作為每一(yi)個請求(qiu)的參數(shu)，服務器接收請求(qiu)自然(ran)能解析(xi)參數(shu)獲得(de)會(hui)話(hua) id，并(bing)借此判(pan)斷(duan)是否來自同(tong)一(yi)會(hui)話(hua)，這(zhe)個思路當然(ran)是可(ke)以的，只是這(zhe)種做法的缺點也十分明顯，就是請求(qiu)的 URL 會(hui)變(bian)得(de)非常長，隱(yin)秘性也很差。

而 Cookie 是瀏(liu)覽器用(yong)來存儲少量數據(ju)的(de)一種機制，數據(ju)以(yi)”key/value“形式存儲，并且瀏(liu)覽器發送 http 請求時自動附帶 Cookie 信息。此(ci)時，有 Cookie 參與的(de)登錄請求的(de)流程就變成了下面這樣 ????

Cookie 和(he) Session 的使用原(yuan)理(li)基本如此(ci)，至(zhi)于這么設置 Cookie，怎(zen)么通(tong)過 Cookie 校驗(yan) Session 就(jiu)不是本文要說的內容了。有(you)興趣的可以查閱相(xiang)資料(liao)。

多系統登錄

不知道你(ni)有沒有留意過，如果你(ni)在瀏覽器中登(deng)錄了百(bai)度網盤之后，再(zai)打開百(bai)度貼吧時就會發現此時你(ni)已經(jing)登(deng)錄成(cheng)功了，這(zhe)種情(qing)況(kuang)就是本節(jie)要說的多系(xi)統登(deng)錄了。

隨(sui)著(zhu)單(dan)系統的蓬勃發展，web 系統由單(dan)系統發展成多系統組成的應用群，換一種說(shuo)法就是「生態」。

隨(sui)著(zhu)集團的規模(mo)不斷增加，系(xi)統(tong)越來越多，復雜(za)性(xing)(xing)隨(sui)之(zhi)巨增，正常情況下，這種復雜(za)性(xing)(xing)應(ying)(ying)該由(you)系(xi)統(tong)內部承擔，而不是(shi)用戶。因(yin)為(wei)對(dui)于一(yi)(yi)(yi)個(ge)好的系(xi)統(tong)應(ying)(ying)該是(shi)，無(wu)論(lun) web 系(xi)統(tong)內部多么復雜(za)，對(dui)用戶而言(yan)，都(dou)應(ying)(ying)該是(shi)一(yi)(yi)(yi)個(ge)統(tong)一(yi)(yi)(yi)的整(zheng)體，也就(jiu)是(shi)說，用戶訪(fang)問 web 系(xi)統(tong)的整(zheng)個(ge)應(ying)(ying)用群與訪(fang)問單個(ge)系(xi)統(tong)一(yi)(yi)(yi)樣，登錄(lu)/注銷只要一(yi)(yi)(yi)次就(jiu)夠了。

如下圖所(suo)示 ????

單系(xi)統(tong)登(deng)錄解決(jue)方案的(de)(de)核心是 Cookie，Cookie 攜帶(dai)會(hui)話 id 在(zai)瀏(liu)覽器(qi)與(yu)服(fu)務(wu)器(qi)之間維護會(hui)話狀態(tai)。但 Cookie 是有限(xian)制的(de)(de)，這個限(xian)制就是 Cookie 的(de)(de)域（通常對應網站(zhan)的(de)(de)域名），瀏(liu)覽器(qi)發送 http 請求時會(hui)自(zi)動攜帶(dai)與(yu)該域匹配的(de)(de) Cookie，而不是所有 Cookie，因此，你在(zai)請求淘寶的(de)(de)時候是絕對不會(hui)攜帶(dai)上(shang)只能在(zai)百度域下生效的(de)(de) Cookie 的(de)(de)。

SSO

單(dan)點(dian)(dian)登錄全稱 Single Sign On（以下簡(jian)稱 SSO），是指在(zai)多(duo)系(xi)統應用群中(zhong)登錄一個系(xi)統，便可在(zai)其他所有系(xi)統中(zhong)得到授權而無需(xu)再次登錄，包(bao)括「單(dan)點(dian)(dian)登錄」與「單(dan)點(dian)(dian)注銷(xiao)」兩部(bu)分。

登錄

不同于(yu)(yu)單系統登(deng)錄，單點登(deng)錄需要引入(ru)一(yi)個獨(du)(du)立(li)(li)的(de)(de)登(deng)錄中心，每個系統可(ke)能并不會提供登(deng)錄入(ru)口，所有的(de)(de)登(deng)錄操作都是通過獨(du)(du)立(li)(li)的(de)(de)登(deng)錄中心實(shi)現的(de)(de)。由于(yu)(yu)這(zhe)一(yi)流(liu)程較多，這(zhe)里以時(shi)序圖的(de)(de)方式來講解。

一(yi)個單點登錄的時序(xu)，簡化后如上圖所示。文(wen)字流程如下：

1.瀏覽器訪問 A 站(zhan)(zhan)點(dian)時(shi)由(you)于未登(deng)(deng)錄(lu)(lu)(lu)，跳轉至 SSO 登(deng)(deng)錄(lu)(lu)(lu)中(zhong)心(xin)2.完成(cheng)在 SSO 登(deng)(deng)錄(lu)(lu)(lu)中(zhong)心(xin)的(de)(de)(de)登(deng)(deng)錄(lu)(lu)(lu)后，登(deng)(deng)錄(lu)(lu)(lu)中(zhong)心(xin)創建一個全局(ju)會話3.SSO 登(deng)(deng)錄(lu)(lu)(lu)中(zhong)心(xin)返回(hui)一個 tikect 給(gei) A 站(zhan)(zhan)點(dian)，并在 SSO 登(deng)(deng)錄(lu)(lu)(lu)中(zhong)心(xin)記(ji)錄(lu)(lu)(lu)下(xia) A 站(zhan)(zhan)點(dian)4.下(xia)次訪問 A 站(zhan)(zhan)點(dian)時(shi)攜帶包含了(le)這個 ticket 的(de)(de)(de) Cookie，A 站(zhan)(zhan)點(dian)收到(dao)請求并創建針對(dui) A 站(zhan)(zhan)點(dian)的(de)(de)(de)局(ju)部會話，給(gei)用(yong)戶(hu)返回(hui)已(yi)登(deng)(deng)錄(lu)(lu)(lu)的(de)(de)(de) A 站(zhan)(zhan)點(dian)頁面

此時如(ru)果用戶想要訪(fang)問 B 站點，那(nei)么(me)流(liu)程如(ru)下所示：

1.瀏覽器訪(fang)問 B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)顯(xian)示未登(deng)錄(lu)(lu)(lu)(lu)(lu)，跳轉(zhuan)至 SSO 登(deng)錄(lu)(lu)(lu)(lu)(lu)中心(xin)2.SSO 登(deng)錄(lu)(lu)(lu)(lu)(lu)中心(xin)發現用戶已經在登(deng)錄(lu)(lu)(lu)(lu)(lu)中心(xin)完成登(deng)錄(lu)(lu)(lu)(lu)(lu)3.SSO 登(deng)錄(lu)(lu)(lu)(lu)(lu)中心(xin)返回一(yi)個(ge) tikect 給 B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)4.B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)拿到(dao)(dao) ticket 后(hou)再請求一(yi)次 SSO 站(zhan)(zhan)點(dian)(dian)(dian)(dian)，驗證無誤(wu)后(hou)寫(xie)入 ticket 到(dao)(dao) Cookie 中，此時(shi) SSO 登(deng)錄(lu)(lu)(lu)(lu)(lu)中心(xin)記錄(lu)(lu)(lu)(lu)(lu)下 B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)5.下次訪(fang)問 B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)時(shi)攜帶包含了(le)這個(ge) ticket 的 Cookie，B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)收到(dao)(dao)請求并創建針(zhen)對 B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)的局部會(hui)話(hua)，給用戶返回已登(deng)錄(lu)(lu)(lu)(lu)(lu)的 B 站(zhan)(zhan)點(dian)(dian)(dian)(dian)頁面(mian)

注銷

注銷(xiao)(xiao)相(xiang)較于登(deng)錄就(jiu)簡單(dan)了(le)(le)許(xu)多(duo)，假(jia)設我在(zai) A 站點注銷(xiao)(xiao)了(le)(le)，那么 SSO 中心接收到注銷(xiao)(xiao)請求后，直接銷(xiao)(xiao)毀保存在(zai) SSO 系(xi)統的全局(ju)會話，然后向所(suo)有(you)注冊系(xi)統發出注銷(xiao)(xiao)請求，各系(xi)統在(zai)接受到注銷(xiao)(xiao)請求后，分別銷(xiao)(xiao)毀自己(ji)的局(ju)部(bu)會話即(ji)可。篇幅(fu)原因(yin)，這里就(jiu)不著重筆墨(mo)來寫了(le)(le)。感興趣(qu)的同學可以自己(ji)畫一(yi)下時序圖。

實現原理

SSO 采用(yong)的是 Client/Server 模式(shi)，為(wei)了實現(xian) SSO，A、B 站(zhan)點都(dou)需要接入 sso-client 包，SSO 登錄中心需要實現(xian) sso-server 包。這兩個包的主要功能如下(xia)。

sso-client

•攔截子系統(tong)未登錄用戶請(qing)(qing)求，跳轉至 sso 認(ren)(ren)證(zheng)中(zhong)心(xin)(xin)•接收并(bing)存儲 sso 認(ren)(ren)證(zheng)中(zhong)心(xin)(xin)發(fa)送的令牌(pai)•與 sso-server 通信(xin)，校驗令牌(pai)的有效性•建立局部(bu)會話•攔截用戶注(zhu)銷(xiao)請(qing)(qing)求，向 sso 認(ren)(ren)證(zheng)中(zhong)心(xin)(xin)發(fa)送注(zhu)銷(xiao)請(qing)(qing)求•接收 sso 認(ren)(ren)證(zheng)中(zhong)心(xin)(xin)發(fa)出的注(zhu)銷(xiao)請(qing)(qing)求，銷(xiao)毀局部(bu)會話

sso-server

•驗證用戶的(de)登錄信息•創建全局會話(hua)•創建授權令(ling)牌•與 sso-client 通信發(fa)送令(ling)牌•校驗 sso-client 令(ling)牌有效性•系統注(zhu)(zhu)冊•接收 sso-client 注(zhu)(zhu)銷請求(qiu)，注(zhu)(zhu)銷所(suo)有會話(hua)

在(zai)了(le)解了(le) sso-client 和 sso-server 的(de)主要功能(neng)后，編碼實(shi)現就(jiu)(jiu)容易(yi)的(de)多了(le)，互聯網上已經有(you)很多相(xiang)關的(de)資料了(le)，這(zhe)里就(jiu)(jiu)不(bu)展開說了(le)。

登錄(lu)態(tai)保護

在了解(jie)了 SSO 之后(hou)，我們知道，在 A 站點(dian)登(deng)(deng)錄后(hou)，下(xia)次再(zai)請求(qiu) A 站點(dian)就(jiu)會攜帶(dai)諸如「A_USER_COOKIE」的(de)一個 Cookie 值(zhi)。在 B 站點(dian)登(deng)(deng)錄后(hou)，下(xia)次再(zai)請求(qiu) B 站點(dian)就(jiu)會攜帶(dai)諸如「B_USER_COOKIE」的(de)一個 Cookie 值(zhi)。

結合著 SSO 的原理，我們再回到本文一開始的問題，如果想要從 A 站點跨域請求 B 站點一個需要登錄的接口，不可避免的一定要重定向到 SSO 站點。因為從 A 站點發出到 B 站點的請求攜帶的是來自 A 站點的 Cookie，B 站點是無法直接解析的。（這里(li)有點繞(rao)，理解一下）

為(wei)了(le)解(jie)決這個(ge)(ge)問題(ti)，可以從前(qian)后(hou)端兩(liang)個(ge)(ge)方式(shi)去(qu)著(zhu)手，提供一下思(si)路。

1.前端方向，捕捉重定向的錯誤單獨處理，只是如果重定向過程中有可能會出現跨域問題。2.后端方向，通過某種途徑，可以讓 B 站點的后端解析來自 A 站點中包含的已經登錄過 SSO 的 Cookie。

根域 Token（共享 Cookie）

所謂根(gen)域(yu)(yu)(yu)即不(bu)同(tong)應用(yong)共(gong)享的(de)(de)域(yu)(yu)(yu)名(ming)部(bu)分(fen)，比如 a.alibaba.com 和(he) b.alibaba.com，根(gen)域(yu)(yu)(yu)就是 alibaba.com。根(gen)域(yu)(yu)(yu) token 是各個(ge)(ge)子(zi)域(yu)(yu)(yu)名(ming)應用(yong)共(gong)用(yong)的(de)(de) Cookie，每(mei)個(ge)(ge)子(zi)域(yu)(yu)(yu)名(ming)應用(yong)的(de)(de)請求都可以接收(shou)到這個(ge)(ge) Cookie 參(can)數，但是每(mei)個(ge)(ge)應用(yong)是否(fou)能用(yong)這個(ge)(ge) Cookie 來建立(li)登錄態，則需要滿足不(bu)同(tong)的(de)(de)條件。

這(zhe)個(ge)條件(jian)是由(you)分(fen)發此根域 Token 的 SSO 中心規定(ding)。

根域 token 的使用時序

時(shi)序如上圖所示，這樣(yang)的(de)好處是，就算我在 A 站(zhan)點(dian)攜帶的(de)是 A 站(zhan)點(dian)的(de) Cookie，也可以去訪(fang)問(wen) B 站(zhan)點(dian)一個(ge)需要登錄的(de)接口。因為 A 站(zhan)點(dian)的(de) Cookie 中(zhong)有一個(ge)全(quan)局的(de)根域 token，B 站(zhan)點(dian)在將(jiang)請(qing)求發送(song)到 SSO 校驗(yan)時(shi)只要有這個(ge)根域 token 即可返(fan)回對(dui)應的(de)用戶信息了。

根域 token 的優勢

根(gen)域(yu)(yu) token 的消費端(duan)在應用側(ce)，由 SDK 封裝這部分邏輯，根(gen)據根(gen)域(yu)(yu) token 建立登錄態。對于原先已(yi)經接入了 sso-client 的 B 應用只需(xu)升級支持根(gen)域(yu)(yu) token 的版本即(ji)可(ke)。

這樣做的(de)好處是，部分沒(mei)(mei)有(you)接 SDK 的(de)應用(yong)也可(ke)以(yi)通過該 token 完成登錄校驗。比如 A 站點的(de)后(hou)端應用(yong)沒(mei)(mei)有(you)更新 sso-client 也無妨，因為 sso-server 升(sheng)級(ji)后(hou)會將根(gen)域 token 下發。A 應用(yong)只需將根(gen)域 token 攜帶給升(sheng)級(ji)后(hou)的(de) B 應用(yong)即(ji)可(ke)。

這樣在 A、B 兩個站點(dian)的(de)前(qian)后(hou)端開(kai)發(fa)(fa)者之前(qian)真正需要做(zuo)出改變的(de)就只(zhi)有 B 站點(dian)的(de)服(fu)務(wu)端開(kai)發(fa)(fa)人(ren)員了，極(ji)大的(de)減少了溝通(tong)帶來的(de)低(di)效(xiao)率與撕逼。（中間件(jian)的(de)升級(ji)獨立與 A、B 站點(dian)的(de)開(kai)發(fa)(fa)之外）

根域 token 的問題

從上述表述發(fa)現，根域 token（即共享 Cookie）的確(que)是一個可行的解決辦法，但(dan)這種(zhong)方案有很多(duo)限制(zhi)：

1.應用群域名統一，基本限制了必須是(shi)同一集團(tuan)下的域2.共享 Cookie 無(wu)法(fa)跨語言(yan)，即服務端技(ji)術棧需統一3.Cookie 不(bu)安全

所以，對于大多數情況，共享(xiang) Cookie 都無法解決統(tong)一登錄的問題。

只(zhi)是，眼尖的小(xiao)伙伴應該意識到了上述(shu)三個問題(ti)，對于集團(tuan)內網來說(shuo)應該都(dou)不是問題(ti)。為什么這么說(shuo)？我們(men)逐(zhu)一(yi)分析下(xia)。

第一點，都(dou)是集(ji)團內網的網站，因此所有的站點都(dou)是“*.alibaba.com”，域名(ming)統一這一點不(bu)存(cun)在限制。其二，集(ji)團內技術(shu)棧統一。其三，大(da)多數系(xi)統都(dou)是內網使用，幾乎不(bu)存(cun)在 Cookie 不(bu)安全的情(qing)況(kuang)。

只不過(guo)(guo)瀏覽器(qi)針對一個(ge)域(yu)名(ming)（根(gen)域(yu)及子(zi)域(yu)）下的 Cookie 數(shu)量有數(shu)量限制，超過(guo)(guo)則(ze)會按規則(ze)逐出部分 Cookie，DevExpress[1]網站給出了一些(xie)瀏覽器(qi)對于 Cookie 的限制，如(ru)下圖所(suo)示 ????

通俗的說就是，對于 chrome 瀏覽器而言，每個域名的上限是180個 Cookie，而這 180 個域名是針對「根域名」的，也(ye)即(ji)：a.alibaba-inc.com, b.alibaba-inc.com 和*.alibaba-inc.com 共享這 180 個限制。

在得知了(le)這個限制之(zhi)后，我們也就理解了(le)為(wei)什么共享 Cookie 的方案(an)即使是在集(ji)團內(nei)也有(you)諸多(duo)的限制了(le)。

Cookie 的逐出規則

這里提一(yi)下，對于超出數量的 Cookie 的逐出規(gui)則，我在查閱(yue)資料的過程中發現(xian)一(yi)些博(bo)客寫(xie)的是 LRA(least-recently accessed)，最近(jin)最少(shao)使用算法。的確(que)，IETF 標準的RFC-6265[2]對 Cookie 逐出策略(lve)的規(gui)范確(que)實(shi)是 LRA 算法。

IETF 是(shi)國(guo)際互聯(lian)(lian)網(wang)工程任務組的簡(jian)稱，IETF 的主要任務是(shi)負(fu)責互聯(lian)(lian)網(wang)相關技術標(biao)準的研發和制(zhi)定，是(shi)國(guo)際互聯(lian)(lian)網(wang)業(ye)界具有一定權威(wei)的網(wang)絡相關技術研究團體。

不過我(wo)們都知道，規(gui)(gui)矩制定的再好也得看(kan)實(shi)現(xian)規(gui)(gui)矩的人(ren)是(shi)什么樣(yang)的。我(wo)們來(lai)看(kan)看(kan)瀏覽器的霸主，chrome 是(shi)如何實(shi)現(xian)的。下圖是(shi)從 chromium 項(xiang)目源碼中截取的部分片段，地址如下 ????

//chromium.googlesource.com/chromium/src/+/refs/heads/main/net/cookies/cookie_monster.cc?spm=ata.21736010.0.0.75512bb3YUmXb0&file=cookie_monster.cc[3]

簡單翻譯一下源碼中的(de)注釋就(jiu)是(shi)，chromium 在源碼中把(ba) Cookie 分為了 6 個優(you)先級，再(zai)移除 Cookie 的(de)時候先按照優(you)先級進行排序，然后再(zai)依次 LRA 算法(fa)刪除。

// 1.  Low-priority non-secure cookies.

// 2.  Low-priority secure cookies.

// 3.  Medium-priority non-secure cookies.

// 4.  High-priority non-secure cookies.

// 5.  Medium-priority secure cookies.

// 6.  High-priority secure cookies.

我們以 www.taobao.com[4] 為(wei)例，打開控制(zhi)臺-應用程序-Cookie，下(xia)圖中的最后(hou)一(yi)欄就是Cookie的優(you)先級。

OAuth 和 SSO 之間的關系

想(xiang)到統一登(deng)(deng)錄(lu)，相信(xin)很多人都會想(xiang)到手機(ji)上使用(yong)的(de)微信(xin)登(deng)(deng)錄(lu)、QQ 登(deng)(deng)錄(lu)等登(deng)(deng)入第三方網(wang)站的(de)案例。

但事實上，上述這些案例涉及到的是一個名為 OAuth 的協議。只是為用戶資源的授權提供了一個安全的、開放而又簡易的標準。OAuth 2.0 為客戶端開發者開發 Web 應(ying)用(yong)，桌面端應(ying)用(yong)程序(xu)，移(yi)動應(ying)用(yong)等提供特(te)定的(de)授權流程。這(zhe)一點和 SSO 有很大的(de)區(qu)別。

通俗的講，OAuth 是為解決不同公司的不同產品實現登錄的一種簡(jian)便授(shou)權方(fang)案(an)，通常(chang)這(zhe)些授(shou)權服(fu)(fu)務(wu)都(dou)是由大客(ke)(ke)戶(hu)網(wang)站提(ti)供的，如騰訊，支付寶，淘寶等(deng)。而使(shi)用這(zhe)些服(fu)(fu)務(wu)的客(ke)(ke)戶(hu)可(ke)(ke)能是大客(ke)(ke)戶(hu)網(wang)站，也(ye)可(ke)(ke)能是小客(ke)(ke)戶(hu)網(wang)站。使(shi)用 OAuth 授(shou)權的好處是，在(zai)為用戶(hu)提(ti)供某些服(fu)(fu)務(wu)時，可(ke)(ke)減少或避免因用戶(hu)懶于注冊(ce)而導致的用戶(hu)流失(shi)問題。

SSO 通常處理的是同一個公司的不同應用間的訪問登錄問題。如企業應用有很(hen)多業務子(zi)系(xi)統，只需登錄一(yi)個系(xi)統，就可以實現不同(tong)子(zi)系(xi)統間的跳轉，而(er)避免了(le)登錄操作(zuo)。

OAuth 與 SSO 的(de)(de)應用(yong)場(chang)景不(bu)同(tong)，雖(sui)然可以使用(yong) OAuth 實現 SSO，但并(bing)不(bu)建議這么做。不(bu)過，如果 SSO 和 OAuth 結合起來的(de)(de)話(hua)，理(li)論上是(shi)(shi)可以打通(tong)各(ge)個公司的(de)(de)各(ge)個不(bu)同(tong)應用(yong)間的(de)(de)登錄，但現實往往是(shi)(shi)殘酷的(de)(de)。

畢竟，這是一個各家都在盡力打造「生態」護城河的互聯(lian)網(wang)時代。

References

[1] DevExpress: //docs.devexpress.com/AspNet/11912/common-concepts/cookies-support

[2] RFC-6265: //tools.ietf.org/html/rfc6265?spm=ata.21736010.0.0.75512bb3YUmXb0#p-5.3

[3] //chromium.googlesource.com/chromium/src/+/refs/heads/main/net/cookies/cookie_monster.cc?spm=ata.21736010.0.0.75512bb3YUmXb0&file=cookie_monster.cc: //chromium.googlesource.com/chromium/src/+/refs/heads/main/net/cookies/cookie_monster.cc?spm=ata.21736010.0.0.75512bb3YUmXb0&file=cookie_monster.cc

[4] www.taobao.com: //www.taobao.com

————————————————

版權聲明(ming)：本(ben)文為CSDN博主「qq_33419925」的原(yuan)創文章，遵循(xun)CC 4.0 BY-SA版權協議，轉載請(qing)附(fu)上原(yuan)文出處(chu)鏈接及本(ben)聲明(ming)。

原文鏈接：//blog.csdn.net/qq_33419925/article/details/119860867