前言

哈嘍大家周四好！時間過的很快，現在已經是三月份了，我的 IdentityServer4 教程也拖了一定的時間了，正好最近有精力學新東西了，主要中間被小伙伴要求寫一個管理后台，目前1.0已經上線（《權限后台系統 1.0 正式上線》），平時也一直開發維護中，希望能達到更優吧。

開發之余，晚上的時候，一直慢慢的學習 Id4，經過了大概半個月的簡單資料尋找和學習，對 Id4 有了初步的認識，發現隨着不斷地學習，其實也沒有剛開始學的時候的那種莫名的恐懼感了（有些小伙伴應該會有和我一樣的心情，就是初學一門技術的時候，內心總是很恐慌的，比如我當時學DDD（地址：《D3模式設計初探與我的計划書》），其實我認為我們恐慌的不是學不會，而是對學習動力的不自信，大膽的學就對了，哪怕最后只知道OAuth是啥，哪怕最后只會照着套模板，也是一種成功！）。

從今天起，我將慢慢的更新 IdentityServer4 系列，因為我還沒有學習完，所以會一邊學習一邊開發，最后形成一個統一的服務項目，初步打算把所有開源的這些項目（Blog.Vue、Blog.tBug、Blog.Admin、DDD等，相關項目參看開源地址 https://github.com/anjoy8）都集中到這一個授權服務器上，我暫時取名為 Blog.IdentityServer ，正好有 vue/js 項目，也有 MVC 項目，{_{把這個系列寫完，前后端分離就差不多了，我也不打算再寫了}，}至於如何搭建倉庫，如何多項目調用，這我先斟酌下，會在以后的文章中，一一說到，因為要用到 EFCore 來處理用戶數據，我個人感覺這還是一個很實用的項目，畢竟這幾個都是實實在在的有血有肉的工程，不只是一個簡單的Demo，自己都可以拿來改改優化優化，直接用了（我這王婆賣瓜也是沒誰了😂）。

本文只是一個開篇講，不會涉及到內容知識點，有很多小伙伴都是一直看我的文章的，特別是看過我寫的JWT 微軟官方自帶授權認證的《JWT授權》，如果之前的你能看懂，或者八成懂，那么這個系列肯定也能，如果以前的都看不懂，(⊙﹏⊙)，只能說咱們緣分太淺👍。

廢話不多說，先把我這兩周的小成果展示下，當然，現在很low，以后會各種優化和改進，預計會有十篇文章，

故事背景

這個是我的第一個 Vue.js 項目 Blog.Vue，（長的很丑，我決定趁着這個機會，把這個美化一下，畢竟我也是看臉的，先用這個練練手，其他的再慢慢更新授權），這個項目首頁不需要登錄，但是詳情頁需要用戶登錄，之前我是走的 Blog.Core 很普通的登錄，那以后全部會走 Blog.IdentityServer 統一授權服務器了，請注意是兩個端口/域名（Vue是6688端口，Id4是5002端口）：

可能你會感覺很簡單，不就是一個客戶端跳轉到授權服務器嘛，然后登錄了再跳轉過來，增加了個用戶角色授權，額，我也感覺挺簡單的，可是我一個月前真不是這么認為的，當時我感覺還是有點兒難度，現在看起來還可以，所以說，Id4想入門還是可以的，至於后期匹配的微服務了，API網關了，負載均衡了，嗯，來日方長。

一、目錄

1、源代碼Github

授權服務：https://github.com/anjoy8/Blog.IdentityServer

資源服務：https://github.com/anjoy8/Blog.Core

客戶端一：https://github.com/anjoy8/Blog.Admin

以后每一個項目修改完登錄授權，這里就列舉一個，爭取把所有項目的授權都遷到 Id4 服務器上。

2、本系列文章一覽

二、到底什么是 IdentityServer4 ？

1、先看看概念

我們通過查看官網，就看到官方很明顯的定義（下文的必看文檔中有官網地址）：

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

IdentityServer是基於OpenID Connect協議標准的身份認證和授權程序，它實現了OpenID Connect 和 OAuth 2.0 協議。

同一種概念，不同的文獻使用不同的術語，比如你看到有些文獻把他叫做安全令牌服務（Security Token Service），
身份提供（Identity Provider），授權服務器（Authorization Server），IP-STS 等等。其實他們都是一個意思，目的都是在軟件應用中為客戶端頒發令牌並用於安全訪問的。

IdentityServer有許多功能：

保護你的資源
使用本地帳戶或通過外部身份提供程序對用戶進行身份驗證
提供會話管理和單點登錄
管理和驗證客戶機
向客戶發出標識和訪問令牌
驗證令牌

2、它有什么優點？

現在的應用開發層出不窮，基於瀏覽器的網頁應用，基於微信的公眾號、小程序，基於IOS、Android的App，基於Windows系統的桌面應用和UWP應用等等，這么多種類的應用，就給應用的開發帶來的挑戰，我們除了分別實現各個應用外，我們還要考慮各個應用之間的交互，通用模塊的提煉，其中身份的認證和授權就是每個應用必不可少的的一部分。而現在的互聯網，對於信息安全要求又十分苛刻，所以一套統一的身份認證和授權就至關重要。

優點：簡單

因此，從實現者的角度來看，我在OAuth 2中看到的主要優點是復雜性降低。它不需要請求簽名過程，這是不是很難，但肯定是fiddly。它大大減少了作為服務的客戶端所需的工作，這是(在現代的，移動世界)你最想要最小化疼痛的地方。在服務器 – >內容提供者端的降低的復雜性使其在數據中心中更具可擴展性。

它將標准的一些擴展編碼為OAuth 1.0a(如xAuth)，現在廣泛使用。

大多數的應用都如上所示，基本上都是通過客戶端對API進行請求（瀏覽器、Web程序、本機應用程序）等。當你的項目到了一定得范圍和大小之后，就有可能去使用Nginx,這個時候,也必須考慮站點的安全性,因為不能讓你的核心業務信任外界任何的調用.當然還有的時候，我們的擁有自己的一套API,為自己服務進行使用，我們不想讓別人來調用我們的，這個時候也可以進行使用。

三、開發白皮書

這里引用下聖傑的圖，聖傑是我知道為數不多的，知識和Code都很強的大佬，曾經有緣聊過兩句。

1、用到了哪些知識點

正如上邊的結構腦圖中顯示的，大概就是這么多，可能你會感覺很多，開始你簡單看一下，有些概念咱們在講 JWT 授權的時候，都說過見過，甚至親身用過，比如：JWT（以及其中的iss、sub、expires等等），Claim， Authentication，access_token，還有所謂的API Resource資源。

OAuth 2.0 簡介 👉
OpenID 和 OAuth 的區別 👉
客戶端授權模式（Client Credentials）👉
密碼授權模式（Resource Owner Password Credentials）👉
授權碼授權模式（Authorization Code Flow，MVC調用）👉
簡化授權模式-OpenID（Implicit Flow，JS/Vue 客戶端調用）👉
混合模式-OpenID & OAuth（Hybrid Flow，角色+策略授權）👉
集成 ASP.NET Core Identity and EntityFramework Core 👉
單點登錄 👉
刷新登錄 RefreshToken 👉
外部登錄（比如QQ、Google、Github等）👉

一.密碼模式（resource owner password credentials）(為遺留系統設計)(支持refresh token)
這種模式是最不推薦的，因為client可能存了用戶密碼
這種模式主要用來做遺留項目升級為oauth2的適配方
當然如果client是自家的應用，也是可以
支持refresh token
使用client_id和client_secret以及用戶名密碼直接獲取秘鑰
請求地址： http://localhost:7010/uaa/oauth/token?grant_type=password&username=lixx&password=dw123456

二.授權碼模式（authorization code）(正宗方式)(支持refresh token)
這種模式算是正宗的oauth2的授權模式
設計了auth code，通過這個code再獲取token
支持refresh token
請求地址：http://localhost:7010/uaa/oauth/authorize?response_type=code&client_id=wx_takeout_client_id&redirect_uri=http://localhost:7010/uaa/login

三.簡化模式（implicit）(為web瀏覽器應用設計)(不支持refresh token)
這種模式比授權碼模式少了code環節，回調url直接攜帶token
這種模式的使用場景是基於瀏覽器的應用
這種模式基於安全性考慮，建議把token時效設置短一些
不支持refresh token
implicit模式（隱式模式）和授權碼模式(authorization_code)訪問差不多，相比之下，少了一步獲取code的步驟，而是直接獲取token
請求：用瀏覽器（此時同授權碼模式，瀏覽器能跳轉到登錄頁面，postman不行）
http://localhost:7010/uaa/oauth/authorize?response_type=token&client_id=wx_takeout_client_id&redirect_uri=http://localhost:7010/uaa/login

四.客戶端模式（client credentials）(為后台api服務消費者設計)(不支持refresh token)
這種模式直接根據client的id和密鑰即可獲取token，無需用戶參與
這種模式比較合適消費api的后端服務，比如拉取一組用戶信息等
不支持refresh token，主要是沒有必要
請求參數：請求頭添加上 client_id和client_secret的basic編碼，請求提添加grant_type必須設置為client_credentials