如何理解基于的OIDC實(shí)現(xiàn)單點(diǎn)登錄的原理

今天就跟大家聊聊有關(guān)如何理解基于的OIDC實(shí)現(xiàn)單點(diǎn)登錄的原理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

不知大家有沒(méi)有體會(huì)，好像看了很多id4(IdentityServer4,下同)的文章，對(duì)：

<ul class=">

• oidc究竟是個(gè)什么蛤?。?/p>

• OAuth3.0和OpenId Connect究竟有啥區(qū)別？

• id4切確是什么東西？

• id4能干些啥？

• id4為什么這么設(shè)計(jì)？

• id4各授權(quán)流程的區(qū)別是啥？

• id4的SSO是基于什么原理？

老實(shí)說(shuō)，這些問(wèn)題我也一懂半懂，還有就是看多了、時(shí)間跨度大，有的以為懂了提筆又忘了。這時(shí)大佬肯定說(shuō)：

”誰(shuí)叫你不去看源碼？“

我默默的留下了兩行老淚：馬上看，馬上看。

但是我覺(jué)得id4很多新手和我一樣都有這困擾，上手門檻確實(shí)有的高。誠(chéng)然看源碼是個(gè)不錯(cuò)的學(xué)習(xí)方法，但上來(lái)就讓新人或使用者看源碼，無(wú)疑很不利于推廣、直接勸退啊，畢竟大部分都是跟我一樣的菜逼（對(duì)不起拖后腿了）。

啥是SSO?

SSO，全稱Single sign-on ：在多個(gè)應(yīng)用系統(tǒng)中，只需要登錄一次，就可以訪問(wèn)其他相互信任的應(yīng)用系統(tǒng)。

比如你登錄京東后查看我的訂單：https://order.jd.com 然后再去查看購(gòu)物車https://cart.jd.com/cart.action就不需要重新登錄。雖然這里頂級(jí)域名一致，但其實(shí)單點(diǎn)登錄并沒(méi)有此要求。

單點(diǎn)登錄，很容易望文生義，以為單點(diǎn)登錄就是限制用戶只能在一處登錄。

下面我們說(shuō)說(shuō)我們我們常用的SSO的常用的實(shí)現(xiàn)方式。

SSO—基于Cookie的實(shí)現(xiàn)簡(jiǎn)析

這種方式比較簡(jiǎn)單，使用也比較廣泛。

比如我有兩個(gè)系統(tǒng)：a.example.com 和 b.example.com，很簡(jiǎn)單，只需要搞個(gè) passport.example.com 登錄成功后往：example.com 這個(gè)頂級(jí)域?qū)懙卿洺晒Φ腸ookie就行了。而后不管你是c.example.com還是d.example.com或是+∞.example.com都只需要驗(yàn)證登錄的cookie就行，簡(jiǎn)單方便。

不過(guò)這種實(shí)現(xiàn)方式有個(gè)比較大的缺陷：

不能跨域，不能跨頂級(jí)的域。

我不能說(shuō)我登錄成功后往jd.com域名下寫cookie吧。還有就是每個(gè)業(yè)務(wù)域名都要做登錄cookie的校驗(yàn)邏輯 ，不過(guò)這算小問(wèn)題。

既然存在問(wèn)題，就解決問(wèn)題吧（這實(shí)在沒(méi)辦法解決發(fā)現(xiàn)問(wèn)題的人?。?/p>

SSO—基于CAS流程實(shí)現(xiàn)簡(jiǎn)析

CAS簡(jiǎn)介

Central Authentication Service，簡(jiǎn)稱：CAS， 是一個(gè)單點(diǎn)登錄框架或者說(shuō)解決方案，開始是由耶魯大學(xué)的一個(gè)組織開發(fā)，后來(lái)歸到apereo管理。同時(shí)CAS也是開源的，遵循apache 2.0協(xié)議，目前代碼放在github上：https://github.com/apereo/cas

打開就驚呆了，看到吧，一堆開源項(xiàng)目在用，這logo閃瞎我的鈦合金狗眼了

我們看看發(fā)生了啥:

站點(diǎn)App1

1. 用戶首次訪問(wèn)web App1，App1發(fā)現(xiàn)用戶未登錄，攜帶目前訪問(wèn)地址302到CAS Server登錄頁(yè)。

2. CAS Server登錄頁(yè)檢查登錄Session不存在，返回一個(gè)登錄頁(yè)面。

3. 填寫賬號(hào)，點(diǎn)擊登錄。

4. CAS Server驗(yàn)證賬號(hào)信息成功，創(chuàng)建一個(gè)Ticket Granting Ticket(TGT),這個(gè)TGT就是當(dāng)前登錄用戶的session key。同時(shí)，創(chuàng)建一個(gè)service ticket并攜帶service ticket key,st key 作為參數(shù)跳轉(zhuǎn)回App1。

5. App1用get發(fā)送st key 去CAS Server驗(yàn)證，驗(yàn)證通過(guò)后返回登錄用戶信息。

6. App1使用返回的登錄用戶信息構(gòu)建當(dāng)前系統(tǒng)的登錄狀態(tài)，并用一個(gè)JSESSIONID標(biāo)記(JSESSIONID是Apache的默認(rèn)名)，并攜帶這個(gè)JSESSIONID重新訪問(wèn)App1。

7. App1驗(yàn)證JSESSIONID，登錄成功，展示登錄成功頁(yè)面。

8. 第二次訪問(wèn)，驗(yàn)證JSESSIONID，直接訪問(wèn)。

站點(diǎn)App2

1. 用戶首次訪問(wèn)web App2，App2發(fā)現(xiàn)用戶未登錄，攜帶目前訪問(wèn)地址302到CAS Server登錄頁(yè)。

2. CAS Server登錄頁(yè)攜帶有App1生成的TGT，那么直接做TCT的驗(yàn)證，驗(yàn)證成功不需要登錄，創(chuàng)建一個(gè)App2的st key，302回App2。

3. 后續(xù)和以上的5,6,7,8 補(bǔ)邏輯相同，不贅述。

CAS的流程大概于此，實(shí)際的實(shí)現(xiàn)可能會(huì)復(fù)雜一點(diǎn)，可能會(huì)遇到各式各樣的問(wèn)題。但有理論支撐，總體實(shí)現(xiàn)起來(lái)還是簡(jiǎn)單，可靠有保證的。

下面說(shuō)說(shuō)基于Id4的OIDC是怎么做單點(diǎn)登錄的。

SSO—基于Id4的OIDC實(shí)現(xiàn)簡(jiǎn)析

先準(zhǔn)備環(huán)境

把官方samples下下來(lái)：https://github.com/IdentityServer/IdentityServer4/tree/master/samples

我刪掉了其他項(xiàng)目，剩下這兩個(gè)，一目了然：

配置IdentityServer，Configs添加這么一個(gè)客戶端：

// sso implicit client
new Client
{
    ClientId = "ssoimplicit",  //這個(gè)client id 跟 MfcImplicit 里面的配置要一致
    ClientName = "sso implicit clinet",
    AllowedGrantTypes = GrantTypes.Implicit,
    RedirectUris = { "http://sso.client.net/signin-oidc">    PostLogoutRedirectUris = { "http://sso.client.net/signout-callback-oidc" },
    AllowedScopes = new List<string>
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile,
        IdentityServerConstants.StandardScopes.Email
    }
}

ok，我們用下抓包工具觀察下登錄流程。

1、受保護(hù)客戶端頁(yè)面的訪問(wèn)

sso.client.net是客戶端，而登錄頁(yè)在sso.client.net服務(wù)端

我們先打開需要登錄才可以訪問(wèn)的：http://sso.client.net/Home/Secure

這里302到了授權(quán)端點(diǎn) http://odic.server.net/connect/authorize

2、授權(quán)端點(diǎn)對(duì)客戶端請(qǐng)求的驗(yàn)證

這就是步驟1中， 302挑戰(zhàn)的授權(quán)端點(diǎn)攜帶的參數(shù)。

點(diǎn)擊登錄，跳轉(zhuǎn)到是否授權(quán)頁(yè)面，這個(gè)頁(yè)面不一定展示，可通過(guò)配置Client的RequireConsent=false，跳過(guò)這個(gè)頁(yè)面。

可以清楚的看到去到了：

http://odic.server.net/connect/authorize/callback

callback，哦，這是一個(gè)登錄回調(diào)，它干了啥呢，我們仔細(xì)看響應(yīng)：

我們看到id_token帶有登錄用戶的信息：

iss：token發(fā)放的服務(wù)器地址

aud：clientid

sid：會(huì)話信息

kid：當(dāng)前token的標(biāo)識(shí)符

name：用戶名

此外還有比如id_token的發(fā)放時(shí)間，過(guò)期時(shí)間，nonce，用戶非機(jī)密信息等等。還有藍(lán)色部分需要使用客戶端公鑰驗(yàn)證的簽名等等。

這個(gè)時(shí)候客戶端已經(jīng)拿到登錄用戶的信息了，這時(shí)客戶端直接使用登錄用戶信息，構(gòu)建當(dāng)前應(yīng)用sso.client.net的登錄狀態(tài)即可。

比如下面的這個(gè) Set名為Implicit的Cookie：

單點(diǎn)登出

單點(diǎn)登出我就不細(xì)說(shuō)了，使用：

//指定登錄方案的方式登出
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);

//或者直接
await HttpContext.SignOutAsync();

暴力點(diǎn)刪除cookie也可以，不過(guò)那只能算是半退出狀態(tài)吧。

總結(jié)

通過(guò)對(duì)以上一個(gè)使用Id4構(gòu)建的OIDC實(shí)現(xiàn)的登錄流程來(lái)看，OIDC的SSO它完全無(wú)光域名的，id4登錄成功后，客戶端通過(guò)使用id_token來(lái)構(gòu)建自身的登錄狀態(tài)，一個(gè)client如此，N個(gè)皆然。

大家好像感覺(jué)這個(gè)SSO的實(shí)現(xiàn)方式跟前面的CAS流程很像誒，我們?cè)倏匆槐榍懊鍯AS的圖，好像是發(fā)現(xiàn)了啥不得了的東西。

沒(méi)錯(cuò)：openid也是基于CAS流程的一個(gè)實(shí)現(xiàn)（我根據(jù)理解猜的 沒(méi)有證據(jù)）。

再多說(shuō)兩句

id4確實(shí)是好東西，暫時(shí)用不上也要多了解、學(xué)習(xí)，最好寫個(gè)博客做個(gè)筆記加深下理解。

在理解的基礎(chǔ)上不要去背各種Flow有啥區(qū)別什么的，知道什么場(chǎng)景下用那種流程就行，也沒(méi)幾個(gè)。

看完上述內(nèi)容，你們對(duì)如何理解基于的OIDC實(shí)現(xiàn)單點(diǎn)登錄的原理有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。