OAuth2.0学习笔记
应用场景
在传统“客户端-服务器”的认证模型中，客户端向服务器请求访问受限的资源时，需要使用资源所有者（即用户）的许可凭证（比如账号密码等）来得到服务器的认证。为了让第三方应用访问受限资源，资源所有者必须提供他的凭证给第三方。这就可能会存在一些问题，比如第三方应用需要存储用户账号密码方便以后使用，但是却以明文形式存储；或者用户授权给第三方应用之后却无法撤回自己的授权，只能更改密码……
原理
OAuth通过引入一个“授权层”（authorization layer），并且将客户端角色和资源所有者角色分离开来解决上述问题。在OAuth中，客户端不能直接登录服务提供商，只能登录授权层，并且客户端需要得到一个access token的令牌才可以访问资源。access token是经过资源所有者同意后，由授权服务器颁发给第三方客户端。客户端再使用该访问令牌访问资源服务器上的受限资源。
例如，一个用户（resource owner）想要授权打印服务（client）访问他云盘（resource server）中的照片，不需要提供账号密码就可以进行打印。他直接与云盘的授权服务器（authorization server）进行验证，然后授权服务器发送访问令牌给打印服务就可以了。
工作流程
OAuth定义了四种角色：
- resource owner：即用户
- resource server：托管资源的服务器
- client：即第三方应用
- authorization server：颁发访问令牌的服务器，可能与资源服务器是同一个
- user agent：一般指浏览器
授权方式如下：
A. 用户打开客户端后，客户端请求用户授权
B. 客户端收到一个授权许可
C. 客户端向授权服务器申请访问令牌
D. 授权服务器对客户端和用户授权许可检验后，如果有效则发放访问令牌
E. 客户端使用访问令牌向资源服务器请求资源
F. 资源服务器验证访问令牌，如果有效则提供资源
授权模式
OAuth提供了四种授权模式。
授权码模式（Authorization Code）
授权码模式是使用一个“授权服务器”作为客户端和用户之间的中介。客户端通过重定向引导用户访问授权服务器，然后携带授权码再返回到客户端。
隐式模式（Implicit）
隐式模式简化了“授权码”步骤，针对一些使用诸如JavaScript等脚本语言的客户端。隐式模式中，客户端不用获得授权码，而是经过用户授权后直接得到令牌。
密码模式（Resource Owner Password Credentials）
用户向客户端提供自己的凭证（如用户名密码），客户端通过这些信息向资源服务器索要令牌。通常用在用户对客户端高度信任的前提下，并且其他授权模式无法使用时。
尽管客户端获得用户凭证，但是用户凭证用于单次请求和交换令牌，客户端不存储用户凭证，而是通过用户凭证换取一个长期访问令牌或更新令牌。
客户端凭证模式（Client Credentials）
客户端以自己名义，向服务提供商进行认证。用户直接向客户端注册，客户端以自己的名义要求服务提供商提供服务，其中不存在授权问题。
令牌
Access Token
访问令牌是用于访问受保护资源的凭证，是一串发给已授权客户端的字符串。令牌有访问范围和时间限制。
Refresh Token
更新令牌是用来获取访问令牌的凭证，由授权服务器颁发给客户端，若当前访问令牌过期，可通过更新令牌申请新的访问令牌。更新令牌从授权服务器发出一般会同访问令牌一起。
安全问题
（未完待续）
