OAuth的 全称为“Open Authorization"，是一种开放性协议，帮助资源的拥有者在不提供自身凭证的前提下授权第三方应用以他的名义存取受保护的资源。
一、OAuth的角色
获得资源拥有者授权的第三方应用获取受保护的资源采用的不是授权者的凭证(用户名和密码),而是一个被称为Access Token的安全令牌。
我们用一个具体例子来说明，假设我们开发了—个集成了新浪微博认证用于发布打折商品消息的App,经过用户授权之后它可以调用新浪微博的Web API获取用户的电子邮箱地址并发布相应的打折消息。 那么OAuth在这个场景中的作用就在于:用户授权该应用(app)以自己的名义调用新浪微博的Web API获取自己的电子邮箱地址,整个过程涉及如下4种角色。
1、资源拥有者(Ro,Resource Owner)
资源的拥有者也是授权者,如果它是—个“ 人 ” , —股就是指最终用户。由于“ 资源 ” 在这个场景中表示为用户的电子邮箱地址,所以资源拥有者自然就是指最终用户。
2、客户端应用(Client)
需要取得资源拥有者授权并最终访问受保护资源的应用,对 于我们的场景来说,就是我们创建的App。
3、资源服务器(Resource server)
最终承载资源的服务器,它一般体现为—个可被调用的Web API。 对于我们提供的场景来说,客户端通过调用新浪微博的Web API 获得用户的电子邮箱地址,所以新浪微博就是资源服务器。
4、授权服务器(AuthoHzatifln server)
它对用户(—般情况下为资源拥有者)和客户端应用实施认证,并在用户授权的情况下向客户端应用颁发Access Token。 在我们提供的场景中,资源服务器和认证服务器合二为一,均为新浪微博。
二、客户端凭证
一般来说,如果需要针对某个第三方认证服务来开发我们自己的应用,我们需要向对应认证服务提供商对该应用进行注册,注册成功之后会得到—个唯一标识该应用的 AppID和Appsecret，它们相当于客户端应用的凭证 , 认证服务利用它们来确定其真实身份。
三、处理流程
虽然OAuth2.0具体采用的执行流程，因采用不同类型的授权方式而有所不同,但是整个流程大体上由客户端应用分别与资源拥有者、授权服务器和资源服务器进行的3轮交互来完成。它被称为经典的“Three LeggedOAuth"。如下图：
1、第一轮 获得用户授权
客户端应用试图获取某个受保护的资源,首先得取得资源拥有者的授权,所以第一轮消息交换旨在让客户端获得资源拥有者(即用户)的授权。 客户端应用得到授权之后会得到一 个被称为Authorization grant的对象,该对象实际上就是—个简单的字符串用以表示成功取得了用户的授权。
2、第二轮 获取Access Token
接下来客户端应用利用此Authorization grant向 授权服务获取用于访问受保护资源所需的Access Token。
3、第三轮 访问目标资源
在成功获得Access Token之后,客户端应用将其附加到针对资源服务器的请求中以获取它所需要的目标资源。
四、Authorization Grant
OAuth2.0中的Authorization Grant代表一种中间凭证(Intermediate CredentiaI),它表示资源拥有者针对客户端应用获取目标资源的授权。体现了授权采用的方式以及Access Token的获取机制。
OAuth2.0定义了如下4种 Authorization Grant类型,我们也可以利用定义其中的扩展机制定制其他类型的Authorization Grant。
1、Implicit
它代表—种“隐式 ” 授权方式,即客户端在取得资源拥有耆(最终用户)授杈的情况下直接获取Access Token,而不是间接地利用获取的Authorization Grant来取 得Access Token。 那么上面介绍的“Three-Logged OAuth” 变成了“Two-Logged OAuth“。参考 OAuth2：隐式授权（Implicit Grant）类型的开放授权
2、Authorization Code
这是最为典型的Authorization Grant,客户端应用在取得资源拥有者授权之后会从授权服务器得到—个Authorization Code作 为Authorization Grant。在它获取寄宿于资源服务器中的目标资源之前需要利用此Authorization Code从授权服务器获取Access Token。参考：OAuth2：授权码（Authorization Code）类型的开放授权
3、Resource Owner Password Credentials
资源拥有者的凭证直接作为获取Access Token的Authorization Grant。这种Authorization Grant类型貌似与OAuth设计的初衷相违背(oAuth的 主要目的在于让客户端应用在不需要提供资源拥有者凭证的情况下能够以他的名义获取受倮护的资源),但是如果客户端程序是值得被信任的 , 用户(资源拥有者)向其提供自己的凭证也是可以接受的。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码（没在客户端注册账号密码）。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。参考：OAuth2：客户端验证授权（Resource Owner Password）类型的开放授权
4、CIient Credentials
客户端应用自身的凭证直接作为它用于获取Access Token的Authorization Grant。这种类型的Authorization Grant适用于客户端应用获取属于自己的资源,换句话说,客户端应用本身相当于资源的拥有者。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"资源或服务提供商"提供资源或服务，其实不存在授权问题。参考：OAuth2：客户端证书授权（Client Credentials）类型的开放授权
五、参考资料