如何理解基于的OIDC實現單點登錄的原理

今天就跟大家聊聊有關如何理解基于的OIDC實現單點登錄的原理，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

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

<ul class=">

• oidc究竟是個什么蛤蟆？

• OAuth3.0和OpenId Connect究竟有啥區別？

• id4切確是什么東西？

• id4能干些啥？

• id4為什么這么設計？

• id4各授權流程的區別是啥？

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

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

”誰叫你不去看源碼？“

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

但是我覺得id4很多新手和我一樣都有這困擾，上手門檻確實有的高。誠然看源碼是個不錯的學習方法，但上來就讓新人或使用者看源碼，無疑很不利于推廣、直接勸退啊，畢竟大部分都是跟我一樣的菜逼（對不起拖后腿了）。

啥是SSO?

SSO，全稱Single sign-on ：在多個應用系統中，只需要登錄一次，就可以訪問其他相互信任的應用系統。

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

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

下面我們說說我們我們常用的SSO的常用的實現方式。

SSO—基于Cookie的實現簡析

這種方式比較簡單，使用也比較廣泛。

比如我有兩個系統：a.example.com 和 b.example.com，很簡單，只需要搞個 passport.example.com 登錄成功后往：example.com 這個頂級域寫登錄成功的cookie就行了。而后不管你是c.example.com還是d.example.com或是+∞.example.com都只需要驗證登錄的cookie就行，簡單方便。

不過這種實現方式有個比較大的缺陷：

不能跨域，不能跨頂級的域。

我不能說我登錄成功后往jd.com域名下寫cookie吧。還有就是每個業務域名都要做登錄cookie的校驗邏輯 ，不過這算小問題。

既然存在問題，就解決問題吧（這實在沒辦法解決發現問題的人啊）

SSO—基于CAS流程實現簡析

CAS簡介

Central Authentication Service，簡稱：CAS， 是一個單點登錄框架或者說解決方案，開始是由耶魯大學的一個組織開發，后來歸到apereo管理。同時CAS也是開源的，遵循apache 2.0協議，目前代碼放在github上：https://github.com/apereo/cas

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

我們看看發生了啥:

站點App1

1. 用戶首次訪問web App1，App1發現用戶未登錄，攜帶目前訪問地址302到CAS Server登錄頁。

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

3. 填寫賬號，點擊登錄。

4. CAS Server驗證賬號信息成功，創建一個Ticket Granting Ticket(TGT),這個TGT就是當前登錄用戶的session key。同時，創建一個service ticket并攜帶service ticket key,st key 作為參數跳轉回App1。

5. App1用get發送st key 去CAS Server驗證，驗證通過后返回登錄用戶信息。

6. App1使用返回的登錄用戶信息構建當前系統的登錄狀態，并用一個JSESSIONID標記(JSESSIONID是Apache的默認名)，并攜帶這個JSESSIONID重新訪問App1。

7. App1驗證JSESSIONID，登錄成功，展示登錄成功頁面。

8. 第二次訪問，驗證JSESSIONID，直接訪問。

站點App2

1. 用戶首次訪問web App2，App2發現用戶未登錄，攜帶目前訪問地址302到CAS Server登錄頁。

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

3. 后續和以上的5,6,7,8 補邏輯相同，不贅述。

CAS的流程大概于此，實際的實現可能會復雜一點，可能會遇到各式各樣的問題。但有理論支撐，總體實現起來還是簡單，可靠有保證的。

下面說說基于Id4的OIDC是怎么做單點登錄的。

SSO—基于Id4的OIDC實現簡析

先準備環境

把官方samples下下來：https://github.com/IdentityServer/IdentityServer4/tree/master/samples

我刪掉了其他項目，剩下這兩個，一目了然：

配置IdentityServer，Configs添加這么一個客戶端：

// sso implicit client
new Client
{
    ClientId = "ssoimplicit",  //這個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、受保護客戶端頁面的訪問

sso.client.net是客戶端，而登錄頁在sso.client.net服務端

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

這里302到了授權端點 http://odic.server.net/connect/authorize

2、授權端點對客戶端請求的驗證

這就是步驟1中， 302挑戰的授權端點攜帶的參數。

點擊登錄，跳轉到是否授權頁面，這個頁面不一定展示，可通過配置Client的RequireConsent=false，跳過這個頁面。

可以清楚的看到去到了：

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

callback，哦，這是一個登錄回調，它干了啥呢，我們仔細看響應：

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

iss：token發放的服務器地址

aud：clientid

sid：會話信息

kid：當前token的標識符

name：用戶名

此外還有比如id_token的發放時間，過期時間，nonce，用戶非機密信息等等。還有藍色部分需要使用客戶端公鑰驗證的簽名等等。

這個時候客戶端已經拿到登錄用戶的信息了，這時客戶端直接使用登錄用戶信息，構建當前應用sso.client.net的登錄狀態即可。

比如下面的這個 Set名為Implicit的Cookie：

單點登出

單點登出我就不細說了，使用：

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

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

暴力點刪除cookie也可以，不過那只能算是半退出狀態吧。

總結

通過對以上一個使用Id4構建的OIDC實現的登錄流程來看，OIDC的SSO它完全無光域名的，id4登錄成功后，客戶端通過使用id_token來構建自身的登錄狀態，一個client如此，N個皆然。

大家好像感覺這個SSO的實現方式跟前面的CAS流程很像誒，我們再看一遍前面CAS的圖，好像是發現了啥不得了的東西。

沒錯：openid也是基于CAS流程的一個實現（我根據理解猜的 沒有證據）。

再多說兩句

id4確實是好東西，暫時用不上也要多了解、學習，最好寫個博客做個筆記加深下理解。

在理解的基礎上不要去背各種Flow有啥區別什么的，知道什么場景下用那種流程就行，也沒幾個。

看完上述內容，你們對如何理解基于的OIDC實現單點登錄的原理有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。