背景
如果资源服务器只是提供资源给自己的应用，使用帐号密码做身份认证倒没什么问题，但如果需要提供资源给第三方应用，就会出现第三方应用需要与资源服务器共享身份凭证，这时会出现几个问题：
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、认证服务器确认无误后，向客户端提供访问令牌。
参考资料