OAuth2.0 基础知识
Tips：本篇已加入，.Net core 3.1 使用IdentityServer4 实现 OAuth2.0 --阅读目录 可点击查看更多相关文章。
前言
如果大家英语比较好 可以看下 OAuth2.0官网（https://oauth.net/2/），当然英语不好也没关系 我们看一下，下面一段描述：
OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容.
开始
做过微信授权的同学们应该都知道，自己开发的应用获取用户openid的过程就是一个OAuth认证授权的流程，
我们看一下微信官方的登录流程图：
这个就是一个 符合OAuth 授权码模式（authorization code）的流程，当我们需要获取 微信的openid（资源）时，不是在开发者应用上让用户输入微信号和密码（其实也没办法输入），
需要用户主动接受授权获取到code，开发者拿着code和事先在微信平台注册的appid和appsecret，去访问微信服务器换取 openid（资源）。
|
（题外话）其实实际操作上可能还要复杂一点：用户授权后其实拿到的时code和iv，并且这个iv用了一次就失效了， 然后服务器后台根据code+appid+appsecret向微信后台发送请求获取openid+session_key 最后服务器后台根据session_key+IV解密encryptedData（AES解密三个参数：密文encryptedData，密钥session_key，偏移向量iv） |
可能大家有点晕乎了怎么一上来直接讲 授权码模式 了，之后的章节中会具体讲解各种模式，这里主要是让大家先有点感觉。
名词定义
（1）Third-party application：第三方应用程序， 即上图中的开发者做的微信小程序。
（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上图中的微信。
（3）Resource Owner：资源所有者，本文中又称"用户"（user）。
（4）User Agent：用户代理，可以时浏览器，app或者是上图描述中的 微信小程序。
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
认证类型
官网上描述的类型有以下几种：
- Authorization Code
- PKCE
- Client Credentials
- Device Code
- Refresh Token
- Legacy: Implicit Flow
- Legacy: Password Grant
本系列主要是讲解Web端的OAuth会讲述里面的 5中类型（不包括 PKCE和 Device Code）
但是我还是会大概说一下这两种模式
|
PKCE模式 ：适用于功能逻辑主要在客户端完成的native app。因为native app没有浏览器那样的cookie支持，CP服务器没有session这样的东西来保存state参数从而防止CSRF，所以使用PKCE的code_verifier和code_challenge来防止CSRF。 Device Code 设备代码： 设备流中的无浏览器或受输入限制的设备使用设备代码授权类型，以将先前获得的设备代码交换为访问令牌。设备代码授权类型值为urn:ietf:params:oauth:grant-type:device_code. |
之后的章节主要重点讲解
- 客户端模式（client credentials）
- 密码模式（resource owner password credentials）
- 简化模式（implicit）
- 授权码模式（authorization code）
而Refresh Token 存在于各个模式之中，随着 .netcore 的流行，IdentityServer4也随之风靡，下面一节中会介绍一下 IdentityServer4 里的一些名词，便于同学们理解之后章节 用ID4 实现各种模式。
| 如果觉得本篇随笔对你有帮助，请点击右下方的 【推荐👍】，或者给作者 【打赏】，感谢大家的支持，这将成为作者继续写作的动力。 |
