前言

我們現在日常生活中，會使用各式各樣的應用程式，層出不窮，其中有基于網頁瀏覽方式的應用，有基于手機端的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 帳號 [email protected] 登錄并同意后，頁面跳回 xxx.com ， xxx.com 拿到了我的“唯一標識”，這個唯一標識可能是 abbcccxxxxxxxddccddxxxx11 ，xxx.com 從這個字串里無法獲得任何 [email protected] 的個人資訊（甚至連郵箱地址也不知道）， 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安全保護，也就是對要傳輸的資料進行加密編碼，安全地傳輸用戶提供的私密資訊，在任何一個安全的系統里都是必要的，否則任何人都可以通過侵入網路，在用戶登錄的時候竊取用戶的用戶名和密碼等資訊，

總結

1. 本篇主要是對Identity Server4的說明，認識到是一個基于OpenID Connect協議標準的身份認證和授權程式，
2. 簡單的涉及對基礎知識的認識以及區別說明，從OAuth、OpenID、OpenID Connect以及JWT等進行對比區別說明，
3. 在后續中會對Identity Server4中常用術語說明，多種授權模式，資料庫持久化以及UI界面優化和常見問題，搭建一個完整可用的認證授權專案，
4. 如果有不對的或不理解的地方，希望大家可以多多指正，提出問題，一起討論,不斷學習,共同進步，

資料

Identity Server 官方檔案

JSON Web Token

理解OAuth 2.0

Identity Server 授權型別

標籤：.NET Core

上一篇：在win10系統下，下面代碼不能修改系統時間，請大家幫看下

下一篇：IdentityServer4系列 | 初識基礎知識點