前言

哈喽大家周四好！时间过的很快，现在已经是三月份了，我的 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