01 选看 OAuth 2.0 简介(上)

原文：https://www.yuque.com/yuejiangliu/dotnet/cg95ni

---

01 选看 OAuth 2.0 简介(上).mp4 (58 MB)

• 本篇基本转载自原博文：Identity Server 4 预备知识 -- OAuth 2.0 简介
• 推荐参阅阮一峰的 OAuth 2.0 的一个简单解释 和 OAuth 2.0 的四种方式

一、什么是 OAuth 2.0？

OAuth 2.0 是一个委托协议，它可以让那些控制资源的人允许某个应用以代表他们来访问他们控制的资源，注意是代表这些人，而不是假冒或模仿这些人。这个应用从资源的所有者那里获得到授权（Authorization）和 access token（访问令牌），随后就可以使用这个 access token 来访问资源。

• 假冒或模仿：客户端复制一份用户名和密码，从而获取相应权限
• OAuth 2.0 是个委托协议：它不假冒用户，客户端应用无法获得用户名和密码（或其他凭证）

OAuth 2.0 特点：

• 关于授权 Authorization

• 仅做授权，无法做身份认证

• Access Token
• 支持多种客户端应用

1、OAuth 2.0 里面的三种角色

• 资源所有者拥有访问 API 资源的权限，并且他还可以委派权限给其他应用来访问 API，资源所有者通常是可以使用浏览器的人
• 受保护的资源就是资源所有者拥有权限去访问的组件，它可以是很多种形式的，最常见的还是 Web API
• 客户端应用就是代表资源所有者访问被保护资源的一个软件，注意它既不是指浏览器，也不是指给你钱让你开发软件的人。在 OAuth 2.0 里面，它是指被保护的 API 资源的消费者

2、委托/委派权限

上面提到 OAuth 2.0 里面，最终用户可以委派他的一部分权限给客户端应用来代表最终用户访问被保护的资源。但要完成这件事，还需要一个桥梁来连接客户端应用和被保护资源，这个组件叫做授权服务器（Authorization Server, AS）。

• 授权服务器也许就是资源服务器，但是大多数情况下它们是不同的服务器
• 授权服务器被受保护的资源信任
• 授权服务器可以发布具有特定目的的 Access Token 给客户端应用

1. 首先客户端需要获得权限，它可能有两种方式来获得权限：

1. 从资源所有者那里直接获得权限（上图所示）
2. 也可以让授权服务器作为中介，从授权服务器那里间接的获得权限（下图所示）

2. 如果使用授权服务器作为中介的话，客户端需要把资源所有者发送到授权服务器（可以理解为最终用户使用的浏览器被重定向到了授权服务器）， 然后资源所有者在这可以对客户端应用进行授权
3. 这时资源所有者要通过身份认证进入授权服务器，通常还会有一个是否同意授权客户端应用请求的选项，点击同意后就授权了。而从客户端应用的角度讲呢，它可以向资源所有者请求他一部分的功能和范围（Scope），在将来，资源所有者可能会逐渐减少它所拥有的功能和范围
4. 至此，上面写的这个动作/东西叫做授权（Authorization Grant）
5. 一旦执行了授权动作也就是客户端得到了授权（授权是一个可以代表资源所有者权限的凭据）。客户端便可以从授权服务器请求 Access Token 了。这个 Access Token 就可以被用来访问被保护的资源了

下图是使用授权服务器作为中介的流程图，除了授权，其它部分和上图表达的都是一个意思：

3、授权 Authorization Grant

授权是一个代表着资源所有者权限的凭据，它可以被客户端应用来获取 Access Token。

OAuth 2.0 里面定义了 4 种类型的授权，分别是：

1. Auhtorization Code 授权码
2. Implicit
3. Resource Owner Password Credentials
4. Client Credentials

OAuth 2.0 还定义了一个扩展机制以便自定义其它的授权类型。

用一句话描述“授权(Authorization Grant)就是获取 Token 的方法”。

• Authorization Code

• 使用授权服务器作为客户端和资源所有者的中介
• 在授权服务器把资源所有者送回（重定向）到客户端的时候带着这个临时的凭据 Authorization Code。它就代表着资源所有者委托给客户端应用的权限
• 在安全方面的一些优点：

• 可以对客户端应用进行身份认证
• Access Token 直接发送到客户端应用，不经过资源所有者的浏览器，所以不会将其暴露给外界，包括资源所有者

• 适合 ASP.NET Core MVC 这类服务器端的客户端应用

• Access Token 直接发送到 Web Server，不经过用户浏览器，不会暴露 Access Token

• Implicit
  

• Authorization Code 的简化版本
• 针对浏览器内的客户端应用，例如 Angular SPA
• 没有授权码发回给客户端应用的步骤，授权服务器直接把 Access Token 发回给了客户端应用，所以在浏览器内能获取到 Access Token
• Implicit 授权确实可以提高浏览器内应用的响应性和效率，毕竟它减少了往返的次数。但是方便可能会带来风险，推荐尽量使用 Authorization Code

• Resource Owner Password Credentials

• 直接使用用户的密码作为授权来获得 Access Token
• 仅当用户和客户端间高度信任且其他授权方式不可用时才可以使用这种授权方式
• 这种凭据只应用于一次请求并用于交换 Access Token，避免客户端存储用户的凭据（密码）

• 通过交换一个长期有效的 Access Token 或使用 Refresh Token都可以达到这种效果

• Client Credentials

• 受保护资源并不属于任意一个用户（没有用户对该资源负责），但客户端任需访问受保护资源

• Device Code
• Refresh Token

• 通常能从授权服务器获得两个令牌：Access Token 和 Refresh Token
• 当 Access Token 要过期时，我们使用 Refresh Token 再获取一个 Access Token

二、授权和认证

• OAuth 2.0 授权 Authorization

• 你能干什么

• Openld Connect 身份认证 Authentication

• 你是谁

三、Identity Server 4

实现了 OAuth 2.0 和 OpenId Connect 协议里面的大部分功能。