IdentityServer4系列 | 初識基礎知識點

艾三元發表於2020-10-05

前言

我們現在日常生活中，會使用各式各樣的應用程式，層出不窮，其中有基於網頁瀏覽方式的應用，有基於手機端的App，甚至有基於流行的公眾號和小程式等等，這些應用，我們不僅要實現各個應用的功能之外，還要考慮各個應用之間的互動作用，其中身份的認證和授權就是每個應用必不可少的的一部分。

所以我們以身份認證和授權這一部分為例，需要考慮各個應用直接的互動，統一管理以及資訊保安問題。

而現在的網際網路，對於資訊保安要求又十分苛刻，所以一套統一的身份認證和授權就至關重要。

所以，我們可以根據Identity Server4框架開發一套統一的身份認證和授權專案應用在平時的多個專案中，實現多平臺應用授權統一管理。

說明

我們通過檢視 IdentityServer4官網，就可以看到給出的定義：

IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core.

OpenID Connect + OAuth2.0 相結合的認證框架

由此可見，IdentityServer是基於OpenID Connect協議標準的身份認證和授權程式，實現了OpenID Connect和OAuth2.0協議的結合。

所以，IdentityServer4是為ASP.NET CORE量身定製的實現了OpenId Connect和OAuth2.0協議的認證授權中介軟體。通常，你構建（或重新使用）包含登入和登出頁面的應用程式，IdentityServer中介軟體會向其新增必要的協議頭，以便客戶端應用程式可以使用這些標準協議與其對話。

2.1 特性

通過不同的文獻使用的術語我們會發現，同一個概念可能存在著多種解釋，比如有些把他稱為安全令牌服務（Security Token Service），
身份提供（Identity Provider），授權伺服器（Authorization Server），IP-STS 等等。其實他們都是一個意思，目的都是在軟體應用中為客戶端頒發令牌並用於安全訪問的。

2.2 功能

引申

3.1 OAuth2.0

OAuth2.0 是OAuth協議的延續，OAuth2.0 關注客戶端開發者的簡易性，為使用者資源提供一個安全的、開放而有建議的標準。是目前流行的授權機制，用於授權第三方應用就可以獲取該使用者資源。因此OAuth是安全的。

為了安全，Oauth2.0 引入了兩個措施：

　　1，Oauth2.0 要求，refresh token 一定是儲存在客戶端的伺服器上的，而絕不能存放在狹義的客戶端（例如移動 app、PC端軟體）上。呼叫 refresh 介面的時候，一定是從伺服器到伺服器的訪問；

　　2，Oauth2.0 引入了 client_secret 機制。即每一個 client_id 都對應一個 client_secret。這個 client_secret 會在客戶端申請 client_id 時，隨 client_id 一起分配給客戶端。客戶端必須把 client_secret 妥善保管在伺服器上，決不能洩露。重新整理 access token 時，需要驗證這個 client_secret。

3.1.1 場景

OAuth2.0 是目前最流行的授權機制，用來授權第三方應用，獲取使用者資料。

（以下以第三方A網站使用者訪問授權獲取在B網站資源為例。參考：理解OAuth 2.0）

為了讓A網站應用訪問在B網站上的儲存的照片、視訊或者聯絡方式等等私密資源，我們可能需要做到的就是讓B網站同意A網站訪問讀取這些資源，那麼，在傳統的方式中，會將自己在B網站中的使用者名稱和密碼告訴A，後者就可以讀取使用者的資源資訊了，但是這樣做存在了嚴重的問題：

A網站為了後續服務，會儲存使用者的密碼，這樣不安全。
B網站必須部署密碼登入方式，才能以此方式獲取，但這種單純的密碼登入也不安全。
A網站使用者獲取某個網站資源的權力，但卻沒有限制獲取的範圍和期限。
當使用者修改密碼的時候，就會收回A網站的權力，但是這樣做，會使得其他所有獲得使用者授權的A應用程式全部失效。
只要有一個A應用程式被破解，就會導致使用者密碼洩漏，以及所有被密碼保護的資料洩漏。

因此，這種方式是不安全的，所以為了解決這種問題，OAuth就解決了這種問題。

允許使用者讓第三方A應用訪問該使用者在B網站上儲存的私密的資源（如照片，視訊，聯絡人列表），而無需將使用者名稱和密碼提供給第三方應用。就比如我用QQ登入部落格園，那部落格園（第三方應用）的暱稱就可以是我的QQ（某網站）暱稱，它獲取到了我的QQ暱稱，並存到了部落格園的資料庫，我以後就一直可以使用QQ來登入部落格園，但是部落格園卻不知道我QQ的使用者名稱和密碼。

3.1.2 說明

OAuth在"客戶端"與"服務提供商"之間，設定了一個授權層（authorization layer）。"客戶端"不能直接登入"服務提供商"，只能登入授權層，以此將使用者與客戶端區分開來。"客戶端"登入授權層所用的令牌（token），與使用者的密碼不同。使用者可以在登入的時候，指定授權層令牌的許可權範圍和有效期。

"客戶端"登入授權層以後，"服務提供商"根據令牌的許可權範圍和有效期，向"客戶端"開放使用者儲存的資料。

（A）使用者開啟客戶端以後，客戶端要求使用者給予授權。
（B）使用者同意給予客戶端授權。
（C）客戶端使用上一步獲得的授權，向認證伺服器申請令牌。
（D）認證伺服器對客戶端進行認證以後，確認無誤，同意發放令牌。
（E）客戶端使用令牌，向資源伺服器申請獲取資源。
（F）資源伺服器確認令牌無誤，同意向客戶端開放資源。

3.1.3 模式

使用者怎樣實現客戶端授權，所以需要通過不同的授權模式讓客戶端可以獲取令牌，進而獲取資源。因此，客戶端獲取授權常用的模式如下：

後續篇章會對這些模式進行說明和搭建應用專案。

3.2 OpenID Connect

OpenID Connect是基於OAuth 2.0規範族的可互操作的身份驗證協議。它使用簡單的REST / JSON訊息流來實現，和之前任何一種身份認證協議相比，開發者可以輕鬆整合。

OpenID Connect允許開發者驗證跨網站和應用的使用者，而無需擁有和管理密碼檔案。

OpenID Connect允許所有型別的客戶,包括基於瀏覽器的JavaScript和本機移動應用程式,啟動登入流動和接收可驗證斷言對登入使用者的身份。

進一步來說：

OpenID Connect是OAuth 2.0協議之上的簡單身份層，用 API 進行身份互動的框架，允許客戶端根據授權伺服器的認證結果最終確認使用者的身份，以及獲取基本的使用者資訊；
它支援包括Web、移動、JavaScript在內的所有客戶端型別；
它是可擴充套件的協議，允許你使用某些可選功能，如身份資料加密、OpenID提供商發現、會話管理；

OpenID Connect vs OpenID 2.0：OpenID Connect完成很多與OpenID 2.0（即認證，對使用者的身份進行認證，判斷其身份是否有效）相同的任務，是API-friendly，定義了可選的簽名和加密的機制；

OAuth 1.0和OpenID 2.0的整合需要擴充套件，而OpenID Connect協議本身就建立在OAuth 2.0之上。

(身份驗證)+ OAuth 2.0 = OpenID Connect

因此，OpenID Connect 是“認證”和“授權”的結合。

我們經常會混淆OpenID和OAuth協議之間的關係，下文會對這兩者進行區分說明。

為什麼開發者要使用OpenID Connect？

因為它很簡單,可靠,安全,並讓他們擺脫困難和危險的儲存和管理別人的密碼。也有好處,它讓使用者的生活更容易在網站註冊和註冊從而減少遺棄。

區別

4.1 OAuth 與 OpenID

首先，來認識兩個英文單詞，也是我們在平時中很容易混淆的。

authorization : n. 授權，認可；批准，委任。
authentication : n. 證明；鑑定；證實。

而在認證授權服務中，也應用了這兩個單詞的表面意思。

OpenID 是一個以使用者為中心的數字身份識別框架，它具有開放、分散性。OpenID 的建立基於這樣一個概念：我們可以通過 URI （又叫 URL 或網站地址）來認證一個網站的唯一身份，同理，我們也可以通過這種方式來作為使用者的身份認證。

OpenID ： 是Authentication，即認證，對使用者的身份進行認證，判斷其身份是否有效，也就是讓網站知道“你是你所聲稱的那個使用者”。

側重的是authentication：即證明 “使用者是誰？”

OAuth ： 是Authorization，即授權，在已知使用者身份合法的情況下，經使用者授權來允許某些操作，也就是讓網站知道“你能被允許做那些事情”。

側重的是authorization ：即授權 “使用者能做什麼？”

由此可知，授權要在認證之後進行，只有確定使用者身份只有才能授權。

4.1.1 場景

OpenID 是證實身份（Authentication）作用的，就好比我們參加大型考試一下，進考場的時候，監考官需要我們拿出身份證和准考證來檢驗，比對是否是同一個人。這個過程就是在驗證 “身份，這就是我”，同時也證實了這不是一個匿名偽造的不可信任資訊。考官比對身份成功後，就會進一步詢問。

比如我用 Google 的 OpenID 服務登入 xxx.com ， xxx.com 先把我導向 Google 的授權頁面，我使用 Google 帳號 test@gmail.com 登入並同意後，頁面跳回 xxx.com ， xxx.com 拿到了我的“唯一標識”，這個唯一標識可能是 abbcccxxxxxxxddccddxxxx11 ，xxx.com 從這個字串裡無法獲得任何 xxx@gmail.com 的個人資訊（甚至連郵箱地址也不知道）， xxx.com 只知道以後只要使用谷歌登入並返回 abbcccxxxxxxxddccddxxxx11 這個識別符號，那就是我在登入。

但是如果你想在認證過程中獲得使用者的其他資訊（比如手機號等）就得多做一步了。

OAuth 是關於授權、許可（Authorization）的，當考官看完比對你的身份後，還要求掏出兜裡的東西，拿出隨身攜帶裡的東西、手機等隨身物品以便檢查，檢查你是否攜帶考場違規物品，這時就需要得到被檢查人的許可才行，被檢查人有權利扭頭就走，但要想進場考試，必須給予許可、配合檢查。這是在回答「我同意讓你對我進一步做些什麼」，是為了在被授予許可權的前提下，更多的獲取除了個人資訊以外，身上攜帶的東西是否包含違規物品。（如：手機，計算器，手錶，非指定文具等）

我想通過微博登入 xxx.com ，xxx.com 要先把我 redirect 到新浪微博的授權頁面，我通過微博帳號登入並授權後，頁面跳回 xxx.com ，xxx.com 拿到我的訪問 token 後還要再呼叫一個介面來獲得我的會員 UID ，這個 UID 就是新浪使用者的“唯一標識”了。

  # 借鑑網友的說明： 
   如今越來越多的網站，以及一些應用程式都開始使用第三方社交平臺賬戶登入，那這裡就會涉及到安全性的問題，隱私的問題，你不能隨意來獲取我的資料，當然你來使用我的資料，你要經過使用者的同意，那這個使用者是不是我平臺上，還是要來向我求證，那在這個過程中，實際上就出現了兩個過程，我們還是直接使用上次的例子來說明，比較直觀，部落格園使用QQ登入，進入部落格園的登入頁，點選使用QQ登入：

    在進入到QQ登入介面後，最開始是要請求認證，使用者輸入QQ號和密碼，點選登入，騰訊互聯會先進行驗證該使用者是否為我的使用者，如果是我的使用者，那麼我會通知你（部落格園），他是我的使用者，你可以使用該賬戶登入你的系統，這個過程就是認證（Authentication），認證就是證明你是誰，你是否是真實存在的，就好像，快遞員來給你送快遞，讓你出示你的身份證，他確定你是本人後，把快遞給你，這就是OpenID。

   而在QQ授權登入下方，有兩給CheckBox核取方塊，可以允許部落格園獲得您的暱稱、頭像、性別，這是在認證之後的事了，在騰訊互聯你是我平臺的使用者後，你可以自己選擇部落格園是否有權去獲取你的相關資訊，當你勾選後，騰訊互聯就把你的這些基本資訊給了部落格園，這個過程就是授權（Authorization），授權就是確定了你是誰後，又把屬於你的東西給了別人，猶如你向快遞員出示了身份證，然後你又把你房門的密碼給了他，並告訴他說，我把房門密碼給你，你幫我放到我客廳裡吧。

可以看出，OAuth 相對於 OpenID 最大的區別就是，網站在認證授權的過程中實際上是拿到了你的帳戶訪問許可權繼而確認你的身份，但是這同時也存在一個安全隱患，因為網站在拿到你的“唯一標識”的同時還拿到了一把你的賬戶的 “臨時鑰匙”。但是你不知道網站會不會拿這把鑰匙“幹壞事”，這個只有站長心裡清楚。同時 OAuth 還比 OpenID 多了幾個額外的請求步驟，登入所費時間一定是長於 OpenID 的。

4.2 OAuth、OpenID 與 OpenID Connect

OpenID Connect 因為其基於OAuth協議（可以看上文OAuth說明），所以OpenID-Connect協議中也包含了client_id、client_secret還有redirect_uri等欄位標識。這些資訊被儲存在“身份認證伺服器”，以確保特定的客戶端收到的資訊只來自於合法的應用平臺。這樣做是目的是為了防止client_id洩露而造成的惡意網站發起的OIDC流程。

OpenID Connect完成很多與OpenID 2.0 相同的任務，是API-friendly，定義了可選的簽名和加密的機制。
OAuth 1.0 和 OpenID 2.0 的整合需要擴充套件，而OpenID Connect協議本身就建立在OAuth 2.0之上。

因此，OpenID Connect 是“認證”和“授權”的結合。

(身份驗證)+ OAuth 2.0 = OpenID Connect (OIDC) = ( Authentication + Authorization + OAuth2.0)

簡要而言，OIDC是一種安全機制，用於應用連線到身份認證伺服器（Identity Service）獲取使用者資訊，並將這些資訊以安全可靠的方法返回給應用。

# 借鑑網友說明
舉個例子。某個使用者使用*Facebook*應用*“What online quiz best describes you?”* ，該應用可以通過*Facebook*賬號登入，則你可以在應用中發起請求到“身份認證伺服器”（也就是Facebook的伺服器）請求登入。這時你會看到介面，詢問是否授權。

 在 OAuth 中，這些授權被稱為scope。OpenID-Connect也有自己特殊的scope--openid ,它必須在第一次請求“身份鑑別伺服器”（Identity Provider,簡稱IDP）時傳送過去。

4.3 JWT 與 OAuth2 .0

要比較JWT和OAuth2，首先要明白一點就是，這兩個根本沒有可比性，是兩個完全不同的東西。

但是既然是沒有可比性，為何還要放一塊比較呢？實際開發應用中，就發現很多拿 JWT和OAuth2.0 作對比，很多情況下，在討論OAuth2的實現時，會把JSON Web Token作為一種認證機制使用。這也是為什麼他們會經常一起出現。

4.3.1 內容區別

JWT是一種認證協議
JWT提供了一種用於釋出接入令牌（Access Token)，並對釋出的簽名接入令牌進行驗證的方法。令牌（Token）本身包含了一系列宣告，應用程式可以根據這些宣告限制使用者對資源的訪問。

一個token包含三部分：header、claims、signature

OAuth2是一種安全的授權框架

提供了一套詳細的授權機制。使用者或應用可以通過公開的或私有的設定，授權第三方應用訪問特定資源。

Oauth2定義了一組想當複雜的規範。涉及到：Roles角色、Client Types客戶端型別、Client Profile客戶端描述、Authorization Grants認證授權、Endpoints終端等。

4.3.2 場景區別

jwt應用場景

1）無狀態的分散式API

JWT的主要優勢在於使用無狀態、可擴充套件的方式處理應用中的使用者會話。服務端可以通過內嵌編碼的宣告資訊，很容易地獲取使用者的會話資訊，而不需要去訪問使用者或會話的資料庫。但是，如果系統中需要使用黑名單實現長期有效的token重新整理機制，這種無狀態的優勢就不明顯了。

Oauth2應用場景

1）第三方認證伺服器

2）大型企業解決方案

API的使用依賴於外部的第三方認證提供者。去認證服務商那裡註冊你的應用，然後設定需要訪問的使用者資訊，比如電子郵箱、姓名等。當使用者訪問站點的註冊頁面時，會看到連線到第三方認證提供商的入口。使用者點選以後被重定向到對應的認證服務商網站，獲得使用者的授權後就可以訪問到需要的資訊，然後重定向回來你的應用中。

4.3.3 歸納說明

Oauth2和JWT是完全不同的兩種東西，一個是授權認證的框架，另一種則是認證驗證的方式方法。OAuth2不像JWT一樣是一個嚴格的標準協議，因此在實施過程中更容易出錯。
兩種方案都需要SSL安全保護，也就是對要傳輸的資料進行加密編碼。安全地傳輸使用者提供的私密資訊，在任何一個安全的系統裡都是必要的。否則任何人都可以通過侵入網路，在使用者登入的時候竊取使用者的使用者名稱和密碼等資訊。