OAuth 2.0 / RCF6749 协议解读

标签：src   这一   import   author   2.0   directly   可靠   来源   between   

　　OAuth是第三方应用授权的开放标准，目前版本是2.0版，以下将要介绍的内容和概念主要来源于该版本。恐篇幅太长，OAuth 的诞生背景就不在这里赘述了，可参考 RFC 6749 。

　　四种角色定义：

1. Resource Owner：资源所有者，即终端用户
2. Resource server：资源服务器，即提供资源存储访问一方
3. Client：通常指第三方应用
4. Authorization server：授权服务器

　　协议端点(URI)：OAuth给授权过程定义了Authorization、Token和Redirection三种端点。Authorization端点用来完成用户授权，在授权码模式（Authorization Code）和隐含模式（Implicit）下被用到；Token端点用来交换与获取access token，不能包含fragment(hash)，在隐含模式（Implicit）下则无需提供该端点；Redirection端点用来接收授权凭证，Public客户端或者Implicit授权的Confidential客户端必须注册其Redirection端点。

　　客户端类型：OAuth根据是否能够进行安全认证定义了两种客户端类型：机密型客户端(Confidential)和公开型客户端(Public)。其中机密型客户端有Web应用，公开型客户端包括User Agent Based和Native应用。客户端的类型注册时确定，不能由授权服务器假定。如果一套应用包含多个不同类型的客户端，这些不同部分应分开单独注册。

　　客户端认证(Client Authentication)：客户端认证当满足授权服务器的安全要求，对机密性客户端的认证可依赖授权服务器发布的认证凭证(比如Password, Public/Private密钥对)，而要对公共客户端进行认证很可能是不可靠的。客户端在每次请求中只能使用一种认证方法，如果客户端持有Password，可采用HTTP Basic认证或request-body传递身份凭证参数方法。客户端认证带来的益处：

1. 强制绑定Refresh Token或Authorization Code到客户端
2. 通过禁用或修改其凭证来快速恢复沦陷客户端
3. 定期凭证轮换，更容易实现认证管理

　　访问令牌(Access Token)是什么？Access Token是访问被保护资源的凭证，一个用来表明被授予权限的字符串，可以是一种可取回授权信息的标识，也可以自包含授权信息于内。可参考 RFC 6750 Bearer Token Usage 。

　　更新令牌(Refresh Token)是什么？当Access Token无效或过期后，客户端将使用Refresh Token来请求授权服务器更新Access Token，除此而外别无他用。通常Refresh Token是授权服务器在发布新Access Token的同时可选发布的，与客户端绑定并长期有效，但是只有授权码模式(Authorization Code)和用户密码模式(Resource Owner Password Credentials)支持Refresh Token。授权服务器须执行如下操作：

1. 对于认证型客户端，要求进行认证
2. 如果请求中包含客户端认证，则执行认证流程，还要保证Refresh Token是发布给认证客户端的
3. 验证Refresh Token是否有效

　　Transport Layer Security (TLS)：授权服务器和资源服务器都必须实现TLS，至于客户端最好也实现TLS。如果客户端没有实现TLS，授权服务器在发出重定向之前应向用户发出安全告警信息。

　　OAuth授权的基本流程如下：

1. 用户打开客户端以后，客户端要求用户给予授权
2. 用户同意给予客户端授权
3. 客户端使用上一步获得的授权，向授权服务器申请令牌
4. 授权服务器对客户端进行授权以后，确认无误，同意发放令牌
5. 客户端使用令牌，向资源服务器申请获取资源
6. 资源服务器确认令牌无误，同意向客户端开放资源

　　OAuth针对不同场景详细定义了四种授权模式：授权码模式（Authorization Code）、隐含模式（Implicit）、用户密码模式（Resource Owner Password Credentials）和客户端模式（Client Credentials）。另外，你也可以使用其他扩展模式。

一. 授权码模式(Authorization Code）

　　授权码模式是流程最严密的授权模式，但是如果被用于Public客户端授权，由于该客户端不能持有客户端证书，因此无法进行身份认证。

• 流程解析： 

  1. 用户访问客户端，后者将前者导向授权服务器
  2. 用户选择是否给予客户端授权
  3. 假设用户给予授权，授权服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码
  4. 客户端收到授权码，附上早先的"重定向URI"，向授权服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见
  5. 授权服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）或者更新令牌（refresh token）

  

　　该流程中客户端先获取授权码再交换访问令牌，似乎获取授权码显得多余？其实授权码除了代表授权范围之外，还避免了暴露访问令牌于用户端：

The authorization code provides a few important security benefits,such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner‘s user-agent and potentially exposing it to others, including the resource owner

• 流程参数解释：此处不再详述，可参考 理解OAuth 2.0 或 RFC6749

二. 隐含模式(Implicit)

　　授权码模式的简化版，跳过了"授权码"这一步，可适用于在浏览器中实现的应用，访问令牌暴露于用户端；在该模式下，授权服务器不会认证客户端，不能使用Refresh Token，一旦Access Token过期，需要重新进行授权处理；隐含模式是一个基于redirection的流，在某些情况下，客户端身份是可以通过redirection URI来验证的。在授权码模式可用的情况下，应权衡隐含模式的便利性和安全性。

• 流程解析：

  1. 客户端将用户导向认证服务器
  2. 用户决定是否给于客户端授权
  3. 假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌
  4. 浏览器向Web-Hosted服务器发出请求，其中不包括上一步收到的Hash值
  5. Web-Hosted服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌
  6. 浏览器执行上一步获得的脚本，提取出令牌
  7. 浏览器将令牌发给客户端

  

• 流程参数解释：此处不再详述，可参考理解OAuth 2.0 或 RFC6749

三. 用户密码模式(Resource Owner Password Credentials)

　　用户向客户端提供自己的用户名和密码，客户端使用这些信息向授权服务器索要授权，但不得保存用户的密码。须在用户对客户端高度信任(比如客户端是操作系统的一部分，或者由一个著名公司出品)，而认证服务器无法在其他授权模式下完成授权的情况下，才能考虑使用这种模式。

• 流程解析：

  1. 用户向客户端提供用户名和密码
  2. 客户端将用户名和密码发给认证服务器，向后者请求令牌
  3. 认证服务器确认无误后，向客户端提供访问令牌

  

• 流程参数解释：此处不再详述，可参考理解OAuth 2.0 或 RFC6749

四. 客户端模式(Client Credentials)

　　顾名思义，客户端模式不是针对单个用户的授权，而是针对客户端授权，适用于受保护资源已经处于客户端控制之下(相当于资源所有者)或者授权服务器已经预先配置好客户端访问权限的的情况。

• 流程解析：

  1. 客户端向认证服务器进行身份认证，并要求一个访问令牌
  2. 认证服务器确认无误后，向客户端提供访问令牌

  

• 流程参数解释：此处不再详述，可参考理解OAuth 2.0 或 RFC6749

五. 授权模式选择

• Web应用一般适用授权码模式(Authorization Code)
• Native应用一般适用授权码模式(Authorization Code)或隐含模式(Implicit)：指安装、运行在用户设备上的客户端，包括桌面应用、手机客户端等

  When choosing between the implicit grant type and the authorization code grant type, the following should be considered:
  
  . Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application‘s inability to keep client credentials confidential.
  . When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once  the access token expires.

• User Agent Based应用一般适用隐含模式(Implicit)

六. 安全风险

• 客户端认证(Client Authentication)：对Public客户端进行认证很可能是不可靠的，授权服务器可以尝试使用redirection URI或征募用户来验证客户端身份

     The authorization server MUST NOT issue client passwords or other
     client credentials to native application or user-agent-based
     application clients for the purpose of client authentication.  The
     authorization server MAY issue a client password or other credentials
     for a specific installation of a native application client on a
     specific device.
     ......
     A valid
     redirection URI is not sufficient to verify the client‘s identity
     when asking for resource owner authorization but can be used to
     prevent delivering credentials to a counterfeit client after
     obtaining resource owner authorization.

   

•  更新令牌(Refresh Tokens)：授权服务器可以给Web客户端和Native客户端发布Refresh Token。Refresh Token在整个生命周期中都应该保持机密性，不能泄露给任何无关的第三方；Refresh Token必须与客户端身份相绑定；Refresh Token不能未获授权而被生成、修改、猜测产生

OAuth 2.0 / RCF6749 协议解读

标签：src   这一   import   author   2.0   directly   可靠   来源   between   

原文地址：http://www.cnblogs.com/XiongMaoMengNan/p/6768535.html