RFC 6749 --- OAuth 2.0

OAuth 2.0 是用于授权的行业标准. OAuth 2.0 致力于简化客户端开发人员, 为 WEB 应用程序, 桌面应用程序, 移动电话和客厅设备提供特定的授权流程.

The OAuth 2.0 Authorization Framework

概述

OAuth 2.0 授权框架使得第三方应用程序去获得有限访问一个 HTTP 服务的能力, 要么是 (这里指的的是第三方应用程序) 作为资源拥有者的代表, 要么被允许第三方应用程序代表自己去获得访问权限.

介绍

在传统的 CS (Client-Server) 认证模型中, 客户端使用一个由服务端认证的资源拥有者的证书 (这里指的是用户密码), 请求受限资源. 为了提供第三方应用程序访问受限资源, 资源的拥有者共享他们的证书给第三方应用程序. 这带来了如下问题和限制:

• 第三方应用程序必须保存资源拥有者的证书以便于未来使用, 特别是明文密码.
• 服务端被要求必须支持密码认证, 尽管使用密码具有与生俱来的安全缺陷.
• 第三方应用程序获得了过多的权限去访问资源拥有者的资源, 同时资源拥有者没有办法限制使用期限或者限制资源访问范围.
• 资源拥有者不能撤销对某一个第三方应用程序的授权, 除非将所有第三方应用程序授权全部撤销, 而且只能采用修改密码的方式去实现撤销授权.
• 任何第三方应用程序的泄露都会导致最终用户的密码和改密码保护的所有数据的泄露.

资源拥有者是第一方, 资源存放服务器为第二方, 应用程序为第三方.

OAuth 通过引入授权层和将资源拥有者和客户端角色分离来解决上述问题. 在 OAuth 中, 客户端请求访问由资源拥有者所控制并由资源服务器托管的资源时, OAuth 颁发一套不同于资源拥有者的证书给客户端.

替代使用资源拥有者证书去访问受限资源, 客户端获得一个访问令牌 — 一个表示特定范围, 有效期和其他访问属性的字符串. 访问令牌是通过资源拥有者承认的认授权务器颁发给第三方应用程序.

角色

OAuth 定义了四个角色:

1. 资源拥有者: 能够授予对受保护资源的访问权限的实体. 当资源拥有者是一个人时, 也称之为终端用户.
2. 资源服务器: 托管受保护资源的服务器, 能够接受并响应使用访问令牌去访问受保护资源的请求.
3. 客户端: 一个应用程序, 代表资源拥有者和其授权, 发起对受保护资源的访问请求.
4. 授权服务器: 获得认证成功用户的授权后, 颁发访问令牌给客户端的服务器.

协议流

     +--------+                               +---------------+
     |        |--(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 ---|               |
     +--------+                               +---------------+

                     Figure 1: Abstract Protocol Flow

• (A): 客户端从资源拥有者处请求授权. 授权请求可以直接向资源拥有者申请, 也可以采用更好的方式, 即通过授权服务器作为中介, 间接的想资源拥有者申请.
• (B): 客户端收到的授权许可, 这就表示资源拥有者已授权的凭证, 使用本规范中定义的四种许可类型之一或使用扩展授权类型表示.
• ©: 客户端通过由授权服务器认证和出具授权许可申请访问令牌.
• (D): 授权服务器对客户端进行身份认证以及核验授权许可, 如果有效, 则颁发访问令牌.
• (E): 客户端通过出具访问令牌进行身份验证, 并向资源服务器请求受保护资源.
• (F): 资源服务器验证访问令牌, 如果有效, 则提供服务请求.

授权许可

授权许可是一个凭证, 表示资源拥有者的授权 (访问属于自己的受限资源的授权), 用于客户端去获取访问令牌. 本规范定义了四种授权许可类型 — 授权码, 隐式许可, 资源拥有者密码凭证, 和客户端凭证.

授权码

通过授权服务器作为客户端和资源拥有者间的媒介来获得授权码. 客户端没有直接向资源拥有者请求授权, 而是将将资源拥有者定向到授权服务器, 后者 (这里指授权服务器) 反过来将资源拥有者和授权码一起定向回客户端.

定向资源拥有者携带授权码返回客户端前, 授权服务器需要对资源拥有者进行身份认证以及获得授权 (这里指受到资源拥有者的授权). 因为资源拥有者仅在授权服务器处进行身份验证, 因此资源拥有者的凭着永远不会与客户端共享.

授权码方式提供了一些安全方面的好处, 例如认证客户端身份的能力, 以及直接将访问令牌传送到客户端, 而无需通过资源拥有者的用户代理来传递它, 并可能将其 (这里指的是访问令牌) 暴露给其他人 (包括资源拥有者).

隐式许可

隐式许可是一种简化了的授权码流, 用于使用诸如 JavaScript 脚本语言的浏览器作为客户端的情况. 在隐式许可流程中, 客户端不是获取一个授权码, 而是直接获取访问令牌. 隐式的含义在于没有颁发中间媒介凭证 (授权码).

在颁发访问令牌的隐式许可流程时, 授权服务器不对客户端进行身份认证. 在某些情况下, 可以通过向客户端交付范文令牌的重定向 URI 来验证客户端的身份. 访问令牌可能会暴露给资源拥有者或者其他能够访问资源拥有者的用户代理的应用程序.

隐式凭证提高了一些客户端 (比如实现在浏览器中的应用程序, 这里指的是 SPA 类的应用程序) 的响应能力和效率, 因为在获得访问令牌的过程中, 减少了通信次数. 然而, 在便利性和安全性上还是需要作出平衡. (这里指的是不能罔顾安全只图便利)

资源拥有者凭证

资源拥有者的密码凭证 (比如: 用户名和密码) 可以直接作为授权许可去过去访问令牌. 仅当资源所有者和客户端之间存在高度信任时 (例如, 客户端是操作系统设备的一部分货具有将高度特权的应用程序), 以及当其他授权许可类型不可用时 (例如, 授权码), 才应该使用这种授权许可类型.

尽管这种许可类型需要定向客户端访问资源拥有者的凭证, 但资源拥有者的凭证仅用于一次单独的请求, 即用于交换访问令牌. 这种许可类型可以通过交换凭证获得长期有效的访问令牌或更新令牌, 来消除客户端需要存储资源拥有者凭证的需要.

客户端凭证

当授权范围受限于客户端控制下的受保护资源或以前与授权服务器一起安排的受保护资源时, 可以将客户端凭证 (或其他形式的客户端身份认证) 用于授权许可.