OAuth 2.0协议学习

简介

OAuth通过引入授权层以及分离客户端角色和资源所有者角色来解决第三方授权中的问题。客户端获得一个访问令牌（一个代表特定作用域、生命期以及其他访问属性的字符串），用以代替使用资源所有者的凭据来访问受保护资源。访问令牌由授权服务器在资源所有者认可的情况下颁发给第三方客户端。客户端使用访问令牌访问托管在资源服务器的受保护资源。OAuth 2.0协议与OAuth 1.0协议实现细节没有太多关联。

角色

• 第三方应用：”Client”
• The API：”Resource Server”
• The Authorization Server
• The User: “Resource Owner”

协议流程

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

OAuth 2.0 流程主要包含以下步骤：

A: 用户打开客户端后，客户端要求用户授权。
B: 用户同意给予客户端授权。
C: 客户端利用授权向认证服务器请求令牌。
D: 认证服务器认证通过，发放令牌。
E: 客户端使用令牌，向资源服务器申请获取资源。
F: 资源服务器确认令牌，返回资源信息。

客户端注册

在OAuth流程之前，首先要注册一个app。注册信息应包含name，website，logo等，除此之外，必须包含 redirct URI用来将用户跳转到web server, 浏览器应用或移动app。

Redirect URIs

OAuth只会将用户重定向到注册URI，这可以防止一些攻击。所有HTTP redirect URI必须使用TLS，因此只会重定向”https”开头的URI，这可以防止授权过程中的数据拦截。原生应用可能注册demoapp://redirect类型URI。

Client ID和secret

注册app后会受到client id和secret。client id是公开信息，用户构建URL或包含在Javascript中，密钥必须保密，如果部署的应用程序无法保密，则不会使用该密钥。

授权

授权许是一个可代表资源所有者授权访问受保护资源的凭据，客户端用它来获取访问令牌。授权过程对应上节步骤A, B。本文定义了四种许可类型：授权码，隐式许可，资源所有者密码凭据和客户端凭据。

授权码模式

授权码模式是功能最完整、流程最严密的授权模式，一般用于web server app, 桌面或移动app。客户端通过后台服务器与服务提供商进行交互。流程如下：

+-----