Oauth2.0[笔记]

背景

如果资源服务器只是提供资源给自己的应用，使用帐号密码做身份认证倒没什么问题，但如果需要提供资源给第三方应用，就会出现第三方应用需要与资源服务器共享身份凭证，这时会出现几个问题：

1、第三方应用需要存储用户的帐号密码（资源服务器的）。

2、第三方越权使用资源，资源服务器无法控制。

3、无法撤销第三方应用的资源访问权限。

4、资源服务器需要支持帐号密的身份认证方式。

Oauth

Oauth是一种授权协议，加入了授权层，客户端访问资源服务器不再使用资源服务器的身份凭证，而是使用授权服务器提供的访问令牌。

Oauth角色

OAuth协议定义了四个角色：

资源所有者（resource owner）

一个能够授权访问受保护资源的实体。一般是用户自己。

资源服务器（resource server）

承载受保护资源的服务器，能够接受访问令牌响应受保护的资源请求。

客户端（client）

应用程序。

授权服务器（authorization server）

服务器成功后向客户端发放访问令牌，验证资源所有者并获得授权。

Oauth协议流程

A、用户在客户端请求某一第三方资源，客户端要求用户给予授权。

B、用户同意给客户端授权，授权服务器将授权信息返回给客户端。

C、客户端使用授权信息，向授权服务器申请令牌。

D、授权服务器验证授权信息，如果有效，则发放访问令牌。

E、客户端使用令牌向资源服务器请求数据。

F、资源服务器验证访问令牌，如果有效，则返回资源。

四种授权方式

用户同意给客户端授权，有四种授权方式。

授权码模式（authorization code）

授权码模式是功能最完整、流程最严密的授权模式。

A、用户访问客户端，后者将前者导向认证服务器。（response_type = code）

B、用户选择是否给予客户端授权。

C、假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

D、客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

E、认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

简化模式（implicit）

简化模式不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

A、客户端将用户导向认证服务器。（response_type = token）

B、用户决定是否给于客户端授权。

C、假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

D、浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

E、资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。

F、浏览器执行上一步获得的脚本，提取出令牌。

G、浏览器将令牌发给客户端。

PS：D到F有一种偷懒的办法，就是客户端能够直接取出accessToken，不需要通过资源服务器脚本获取。

密码模式（resource owner password credentials）

密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下。

A、用户向客户端提供用户名和密码。（grant_type = password）

B、客户端将用户名和密码发给认证服务器，向后者请求令牌。

C、认证服务器确认无误后，向客户端提供访问令牌。

客户端模式（client credentials）

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

A、客户端向认证服务器进行身份认证，并要求一个访问令牌。（grant_type = clientcredentials）

B、认证服务器确认无误后，向客户端提供访问令牌。

参考资料

1、https://tools.ietf.org/html/rfc6749

2、http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html