概述

OAuth2.0的最好的文档，莫过于RFC 6749。OAuth2.0本身是一个比较灵活的标准，能够适配应用到各种场景。本文主要是对文档的翻译以及加上部分个人的理解。

角色

OAuth定义了4个角色

• resource owner
  能够对受保护的资源进行授权的实体。当resource owner是人的时候，它是指终端用户
• resource server
  持有受保护的资源的服务器，使用access tokens能够接收和响应对受保护资源的请求
• client
  在resource owner的行为和授权下，请求受保护资源的应用。“client”没有特指任何实现特性（比如，无论应用执行在服务器，桌面或者其他设备上）
• authorization server
  当成功认证了resource owner并且获得授权后，分发access tokens给client的服务器。

Client类型

OAuth定义了两种client类型，根据它们与authorization server安全地授权的能力（维护client credentials的保密性的能力）。

• confidential
  能够维护它们的credentials的保密性（例如，对client credentials的访问进行限制的安全的服务器上实现的client）的client。具体的应用类型：web application

• public
  不能够维护它们的credentials的保密性的client（例如，执行在resource owner的设备上的client，比如安装的本地应用或者基于浏览器的web应用）。具体的应用类型：user-agent-based application， native application

协议流程

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

(A) client从resource owner请求认证。认证请求可以直接向认证服务器请求或者间接地通过authorization server
(B) client收到一个authorization grant，实际是代表了resource owner的认证的证书，使用文档中定义的四种授权类型或者扩展的授权类型来表示
(C) client向authorization server提交authorization grant，请求授权获取access token，
(D) authorization server授权client，验证authorization grant，如果是有效的，分发access token
(E) client从resource server提交access token请求受保护的资源
(F) resource server验证access token，如果是有效的，接收请求

授权模式（Authorization Grant）

对于协议的流程来说，最灵活的部分就是上面提到的(B)中Authorization Grant。也就是说(C)请求授权access token所提交的authorization grant，根据授权模式不同是不一样的。

RFC 6749文档中提及了4种授权模式：

• Authorisation code grant
• Implicit grant
• Resource owner credentials grant
• Client credentials grant

Authorisation Code

authorization code是通过使用authorization server作为client和resource owner的中间人获取的。client把resource owner导向到authorizatoin server（通过它的用户代理），然后反过来带着authorization code把resource owner导向回client。

在附带着authorization code把resource owner导向回client之前，authorization server认证resource owner并且获取授权。 因为resource owner只通过authorization server进行验证，resource owner的证书不需要和client共享。

authorization code提供了一些重要的安全方面的好处，比如说可以验证client，并且直接传递access token给client，不需要经过resource owner的用户代理，所以不会潜在地暴露给别人包括resource owner本身

下面的图演示整个流程

Implicit

implicit授权为在浏览器中使用脚本语言（Javascript）实现的客户端而优化的简单版的authorization code流程。在implicit的流程中，client直接请求一个access token(作为resource owner授权的结果)而不是为client请求一个authorization code

在implicit的流程中请求一个access token时，authorization server不验证客户端。在一些情况下，client的标示，可以通过，用来传递access token给client的redirection URI来验证。access token会暴露给resource owner或者其他访问resource owner的用户代理的应用程序（因为首先要经过用户代理的重定向才能把access token传递给client）。

Implicit授权提高了响应效率以及一些client的效率（比如用浏览应用实现的client），因为它减少了为了获取access token而进行的来回交互。然而，这些便利应该和安全影响进行权衡。

Resource Owner Password Credentials

resource owner password credentials（比如说用户名密码）， 能够被直接用作authorization grant来获取access token。credentials只应该用在resource owner和client之间是高度信任的情况下（例如，client是设备操作系统的一部分或者一个具有高权限的应用），并且其他的授权方式不可用的情况下。

尽管这种方式需要client直接访问resource owner的credentials，resource owner的credentials仅被用于一次请求来交换access token。这种授权类型能够通过用credentials交换长期存活的access token或者refresh token，排除client了为了以后的使用而保存resource owner的credentials的需要。

Client Credentials

当授权范围被限制在，client控制下的受保护的资源的时候或者，受保护的资源事先和authorization server协商好的时候，能够使用client credentials（或者其他形式的client验证）。当client是在以自己名义行动（client就是就是resource owner），或者根据和authorization server事先协商好的授权访问受保护的资源的时候，使用Client credentials。

其他

Access Token Scope

authorization server允许client获取access token的时候，指定scope参数。 这样获取的access token之后只能访问对应的scope的资源。资源服务器需要实现对资源的scope进行保护。scope的参数的值可以是多个用空格间隔的字符串，大写小敏感。authorization server需要定于client和其可获取的scope的对应关系，同时定义一个默认的scope。当请求access token实际获取的scope与client请求的scope不同的时候，authorization server需要返回实际授予的scope参数。

实际应用的时候，可以实现一个类似RBAC的简化模型。authorization server定义的scope相当于定义了资源所属的角色。client定义多个需要的scope为一个access token type，相当于给用户赋予角色。根据client的不同，赋予不同的角色，即可实现对同一用户在不同的client中所能访问的资源的权限控制。