OAuth 是第三方应用授权的开放标准,目前版本是 2.0 版,以下将要介绍的内容和概念主要来源于该版本。恐篇幅太长,OAuth 的诞生背景就不在这里赘述了,可参考 RFC 6749 。
四种角色定义:
协议端点 (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 传递身份凭证参数方法。客户端认证带来的益处:
访问令牌 (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。授权服务器须执行如下操作:
Transport Layer Security (TLS):授权服务器和资源服务器都必须实现 TLS,至于客户端最好也实现 TLS。如果客户端没有实现 TLS,授权服务器在发出重定向之前应向用户发出安全告警信息。
OAuth 授权的基本流程如下:
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'
二. 隐含模式 (Implicit)
授权码模式的简化版,跳过了 "授权码" 这一步,可适用于在浏览器中实现的应用,访问令牌暴露于用户端;在该模式下,授权服务器不会认证客户端,不能使用 Refresh Token,一旦 Access Token 过期,需要重新进行授权处理;隐含模式是一个基于 redirection 的流,在某些情况下,客户端身份是可以通过 redirection URI 来验证的。在授权码模式可用的情况下,应权衡隐含模式的便利性和安全性。
- 1. 客户端将用户导向认证服务器
- 2. 用户决定是否给于客户端授权
- 3. 假设用户给予授权,认证服务器将用户导向客户端指定的"重定向URI",并在URI的Hash部分包含了访问令牌
- 4. 浏览器向Web-Hosted服务器发出请求,其中不包括上一步收到的Hash值
- 5. Web-Hosted服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌
- 6. 浏览器执行上一步获得的脚本,提取出令牌
- 7. 浏览器将令牌发给客户端
三. 用户密码模式 (Resource Owner Password Credentials)
用户向客户端提供自己的用户名和密码,客户端使用这些信息向授权服务器索要授权,但不得保存用户的密码。须在用户对客户端高度信任 (比如客户端是操作系统的一部分,或者由一个著名公司出品),而认证服务器无法在其他授权模式下完成授权的情况下,才能考虑使用这种模式。
- 1. 用户向客户端提供用户名和密码
- 2. 客户端将用户名和密码发给认证服务器,向后者请求令牌
- 3. 认证服务器确认无误后,向客户端提供访问令牌
四. 客户端模式 (Client Credentials)
顾名思义,客户端模式不是针对单个用户的授权,而是针对客户端授权,适用于受保护资源已经处于客户端控制之下 (相当于资源所有者) 或者授权服务器已经预先配置好客户端访问权限的的情况。
- 1. 客户端向认证服务器进行身份认证,并要求一个访问令牌
- 2. 认证服务器确认无误后,向客户端提供访问令牌
五. 授权模式选择
- 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.'
六. 安全风险
- 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.
来源: http://www.cnblogs.com/XiongMaoMengNan/p/6768535.html