IdentityServer4系列 | 初識基礎知識點

1、前言

咱們如今平常生活中，會使用各式各樣的應用程序，層出不窮，其中有基於網頁瀏覽方式的應用，有基於手機端的App，甚至有基於流行的公衆號和小程序等等，這些應用，咱們不只要實現各個應用的功能以外，還要考慮各個應用之間的交互做用，其中身份的認證和受權就是每一個應用必不可少的的一部分。

因此咱們以身份認證和受權這一部分爲例，須要考慮各個應用直接的交互，統一管理以及信息安全問題。

而如今的互聯網，對於信息安全要求又十分苛刻，因此一套統一的身份認證和受權就相當重要。

因此，咱們能夠根據Identity Server4框架開發一套統一的身份認證和受權項目應用在平時的多個項目中，實現多平臺應用受權統一管理。

2、說明

咱們經過查看 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、引伸

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、區別

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安全保護，也就是對要傳輸的數據進行加密編碼。安全地傳輸用戶提供的私密信息，在任何一個安全的系統裏都是必要的。不然任何人均可以經過侵入網絡，在用戶登陸的時候竊取用戶的用戶名和密碼等信息。

5、總結

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 受權類型