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 实现各类模式。

 

 

若是以为本篇随笔对你有帮助，请点击右下方的 【推荐👍】，或者给做者 【打赏】，感谢你们的支持，这将成为做者继续写做的动力。