OAuth2.0

1、OAuth是什么？

首先先了解一下什么oauth协议，主要解决了什么问题。

先给大家举个例子

小新现在想要使用一个“在线打印服务”来打印一些照片，同时小新的照片都存储在了“云网盘”上，按照传统的方式小新要怎么做呢？

1、将照片从“云网盘”上down下来，在上传到“在线打印服务”，然后开始打印。

2、下载/上传太麻烦了，小新可以直接把“云网盘”的账号和密码告诉“在线打印服务”，由“在线打印服务”下载照片在上传。

对于上面的两种方法，方法一太麻烦但是相对于小新来说是安全的；方法二对于小新是比较方便，但是将账号密码告诉了“在线打印服务”就相当于把所有的“云网盘”资料交给了它，这肯定是不可取的。

所以，为了解决类似上面的问题，Oauth协议诞生了。

• OAuth 即 Open standard for Authorization
• OAuth是一个网络开放协议。为保证用户资源的安全授权提供了简易的标准

oauth的好处：

• 允许用户授权第三方网站或应用，访问用户存储在其它网站上的资源，而不需要将用户名和密码提供给第三方网站或分享他们数据的内容
• 对于用户:免去了繁琐的注册过程,降低了注册成本,提高了用户体验
• 对于消费方:简化自身会员系统的同时又能够带来更多的用户和流量。
• 对于服务提供者:围绕自身进行开发,增加用户粘性

目前oauth和版本是2.0即oauth2.0，而且不向下兼容。本文章主要针对oauth2.0进行讲解。

2、Oauth2.0协议流程

2.1 角色

在介绍协议流程之前先要说明一下oauth2.0定义的几个角色：

resource owner**：**资源所有者，这里可以理解为用户。

client**：**客户端，可以理解为一个第三方的应用程序。

resource server**：**资源服务器，它存储用户或其它资源。

authorization server**：**授权服务器，它认证resource owner的身份，为 resource owner提供授权审批流程，并最终颁发授权令牌(Access Token)。

user-agent**：**用户代理，这里可以理解为“浏览器”。

这里面有个需要注意的地方，这里只是在逻辑上把authorization server与resource server区分开来；在物理上，authorization server与resource server的功能可以由同一个服务器来提供服务。

2.2 流程

（A）用户打开客户端以后，客户端要求用户给予授权。

（B）用户同意给予客户端授权。

（C）客户端使用上一步获得的授权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，同意向客户端开放资源。

上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

下面就介绍一下oauth2.0获取授权的几种方式。

3、Oauth2.0授权模式

3.1 应用程序注册(Application Registration)

对于一个应用程序来说，如果它想要使用OAuth，那么首先它要在服务提供商那里注册。

应用程序要提供：

• 应用程序名称(Application Name)
• 应用程序网站(Application Website)
• 回调URL(Redirect URI or Callback URL)

在用户同意授权(或者拒绝)之后，服务提供商会将用户重新导向这个Callback URL，这个Callback URL要来负责处理授权码或者访问令牌。

应用程序注册完成之后，服务提供商会颁发给应用程序一个“客户端认证信息(client credentials)”。Client Credential包括：

• Client ID
  • 提供给服务提供商，用于识别应用程序
  • 用于构建提供给用户请求授权的URL
• Client Secret
  • 提供给服务提供商，用于验证应用程序
  • 只有应用程序和服务提供商两者可知

3.2 授权模式

oauth2.0提供了四种授权模式，开发者可以根据自己的业务情况自由选择。

• 授权码授权模式（Authorization Code Grant）
• 隐式授权模式（Implicit Grant）
• 密码授权模式（Resource Owner Password Credentials Grant）
• 客户端凭证授权模式（Client Credentials Grant）

3.2.1 授权码授权模式（Authorization Code Grant）

流程介绍

（A）用户访问客户端，客户端将用户引导向认证服务器。

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

（C）如用户给予授权，认证服务器将用户引导向客户端指定的redirection uri，同时加上授权码code。

（D）客户端收到code后，通过后台的服务器向认证服务器发送code和redirection uri。

（E）认证服务器验证code和redirection uri，确认无误后，响应客户端访问令牌（access token）和刷新令牌（refresh token）。

请求示例

（A）步骤：客户端申请认证的URI

https://www.example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read&state=xxx
1

参数说明：

response_type：授权类型，必选项，此处的值固定为"code"
　　client_id：客户端的ID，必选项
　　redirect_uri：重定向URI，必选项
　　scope：申请的权限范围，可选项
　　state：任意值，认证服务器会原样返回,用于抵制CSRF(跨站请求伪造)攻击。

（C）步骤：服务器回应客户端的URI

https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xxx
1

参数说明：

code：授权码，必选项。授权码有效期通常设为10分钟，一次性使用。该码与客户端ID、重定向URI以及用户，是一一对应关系。
　　state：原样返回客户端传的该参数的值。

（D）步骤：客户端向认证服务器申请令牌

https://www.example.com/v1/oauth/token?client_id=CLIENT_ID&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
1

参数说明：

client_id：表示客户端ID，必选项。
　　grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
　　code：表示上一步获得的授权码，必选项。
　　redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。

注意：协议里没有提及client_secret参数，建议可以使用此参数进行客户端的二次验证。

（E）步骤：响应（D）步骤的数据

[](javascript:void(0)