开放授权协议-OAuth2.0

一、OAuth协议简介

1.1 OAuth是什么？

OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。

与以往的授权方式不同之处是OAuth的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAuth是安全的。OAuth是Open Authorization的简写。

1.2 OAuth协议特点

• 简单：不管是OAuth服务提供者还是应用开发者，都很易于理解与使用。
• 安全：没有涉及到用户密钥等信息，更安全更灵活。
• 开放：任何服务提供商都可以实现OAuth，任何软件开发商都可以使用OAuth。

1.3 OAuth角色划分

• 服务提供方（Resource Server）：用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。
• 用户（Resource Owner）：存放在服务提供方的受保护的资源的拥有者。
• 客户端（Client）：要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。
• 认证授权中心（Authorization Server）：服务器在成功地对资源所有者进行身份验证并获得授权后向客户端发出访问令牌。

二、OAuth2.0

2.1 概述

• OAuth2.0是OAuth协议的延续版本，但不向前兼容OAuth 1.0（即完全废止了OAuth1.0）。

• OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC。

• 对于用户相关的 OpenAPI（例如获取用户信息，动态同步，照片，日志，分享等），为了保护用户数据的安全和隐私，第三方网站访问用户数据前都需要显式地向用户征求授权。

2.2 四种授权模式

授权前提：不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。

• Authorization Code（授权码模式）：正宗的OAuth2的授权模式，客户端先将用户导向认证服务器，认证用户成功后获取授权码，然后进行授权，最后根据授权码获取访问令牌；
• Implicit（隐藏式）：和授权码模式相比，取消了获取授权码的过程，直接获取访问令牌；
• Password（密码模式）：客户端直接向用户获取用户名和密码，之后向认证服务器获取访问令牌；
• Client Credentials（客户端凭证模式）：客户端直接通过客户端认证（比如client_id和client_secret）从认证服务器获取访问令牌。

2.3 应用场景

• 原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、请求后台数据。
• 前后端分离单页面应用：前后端分离框架，前端请求后台数据，需要进行OAuth2安全认证，比如使用vue、react或者h5开发的app。
• 第三方应用授权登录，比如QQ，微博，微信的授权登录。

三、授权过程

四、接入步骤

此处以CSDN通过微博进行社交登录为例：

• 步骤一：引导用户到微博的认证地址 https://api.weibo.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=YOUR_REGISTERED_REDIRECT_URI

  • client_id：微博网站接入提供的 APP KEY；

  • redirect_uri：认证后重定向的地址。

• 步骤二：用户同意授权，重定向到上面设置的地址并携带 code：http://www.blog.csdn.net/success?code=CODE；

• 步骤三：使用 code 请求微博提供的地址换取 access_token：https://api.weibo.com/oauth2/access_token?client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=authorization_code&redirect_uri=YOUR_REGISTERED_REDIRECT_URI&code=CODE

  • client_id：APP KEY；
  • client_secret：APP SECRET；
  • redirect_uri：认证后重定向的地址 http://www.blog.csdn.net/success；
  • code：第二步返回的 code 值。

• 返回响应报文：

{
	"access_token": "2.00pDpyxGd3J5bEef6b98778e0ZKsu4",
	"remind_in": "158679999",
	"expires_in": 158679999,
	"uid": "6397634587",
	"isRealName": "true"
}

五、协议总结

• 优点：
  • 更安全，客户端不接触用户密码，服务器端更易集中保护。
  • 广泛传播并被持续采用。
  • 短寿命和封装的token。
  • 资源服务器和授权服务器解耦。
  • 集中式授权，简化客户端。
  • HTTP / JSON友好，易于请求和传递token。
  • 考虑多种客户端架构场景。
  • 客户可以具有不同的信任级别。
• 缺点：
  • 协议框架太宽泛，造成各种实现的兼容性和互操作性差。
  • 不是一个认证协议，仅仅只是授权，所以并不能告诉你任何用户信息。

六、结束语

---

“-------怕什么真理无穷,进一寸有一寸的欢喜。”

微信公众号搜索：饺子泡牛奶。