技术代码优雅干货

说说OAuth那点事

2015-06-07  本文已影响9467人  Jason_Yuan

今年年初，第一份实习，接触了如何使用Facebook API, Twitter API...去获取数据，自动发个Facebook什么的，也在那会听到了这个词-OAuth. 不明觉厉。无奈最近实习中又接触了，实在不想迷迷糊糊了，决心搞清楚，在拜读了各路大牛的文章之后，决定为自己写个总结。

目录###

1. 什么是OAuth
2. OAuth 历史版本
3. OAuth 1.0
4. OAuth 2.0

OAUTH

1. 什么是OAuth ?

官网这样说...

An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

2. OAuth 历史版本

3. OAuth 1.0

OAuth 1.0 协议过于复杂，易用性差，所以并没有得到普及，下文中给出了授权的流程图，可以简单了解了解，现在很少有用的了。

OAuth Authentication Flow

关于OAuth 1.0， 想了解的可以看看这些：

4. OAuth 2.0

OAuth 2.0是目前的最新版本，OAuth 2.0不兼容OAuth 1.0。这篇文章主要讲讲OAuth 2.0，并以此展开。

先来说一个场景：比如你第一次打开简书官网，想要注册一个账号。你会看到简书允许你通过新浪微博账号登陆。当你点击之后，需要你登陆微博。之后会出现“是否同意简书获取你的个人信息”等等，如果你选择授权，之后会跳转回简书。你会发现你在简书的用户名就是你微博的用户名。然后，你会发出一条新的微博比如“我加入了简书，一个基于内容分享的社区！”(这只是举个例子，不知道简书有没有这样做)。

好了，这回开始进入正题

4.1 角色(roles)

OAuth 2.0 定义了四个角色：

资源服务器与授权服务器可以是同一台服务器，这里分开主要是便于解释清楚OAuth协议。从程序开发者的角度，这两个都是service's API会执行的事情。

在了解完OAuth中的四个角色之后，我们看看这四个角色之间是如何互动的。下面是基本运行流程。

Abstract Protocol Flow
  1. 应用程序向用户请求给予授权，以便获取服务器资源

4.2 应用程序注册(Application Registration)

对于一个应用程序来说，如果它想要使用OAuth，那么首先它要在服务提供商那里注册。一般出现在网站的“developer”或者“API”部分。

应用程序要提供：

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

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

4.3 授权许可类型(Authorization grant types)

OAuth 2.0 定义了四种授权模式：

4.4 授权码模式(Authorization Code)

Authorization Code Flow
第一步：客户端把用户代理定向到授权终端(Authorizaiton Endpoint)
https://www.example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
第二步：用户授权应用程序

用户点击上述URI之后，用户首先要登陆，证明其身份。然后选择同意授权应用程序可以访问他们的账户或者拒绝。

是否允许**简书**访问你的**微博账户**
第三步：应用程序获取授权码

如果用户同意授权，服务提供商会将用户代理重定向到第一步中的redirect_uri，并且会包含授权码。

https://www.jianshu.com/callback?code=AUTHORIZATION_CODE
第四步：应用程序请求授权令牌

应用程序向API token终端发送刚刚获得的授权码，以及认证信息。

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

URI中包括：

第五步：应用程序获得授权令牌

如果上一步验证有效，API将返回一个HTTP回复。

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read"}

HTTP回复中包含：

4.5 隐式授权模式(Implicit)

Implicit Flow
第一步：客户端把用户代理定向到授权终端(Authorizaiton Endpoint)
https://www.example.com/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
第二步：用户授权应用程序

用户点击上述URI之后，用户首先要登陆，证明其身份。然后选择同意授权应用程序可访问他们的账户或者拒绝。

是否允许**简书**访问你的**微博账户**
第三步：用户代理收到授权令牌

假设用户同意授权，授权服务器重定向用户代理到第一步提到的redirect_uri。并在URI fragment中包含授权令牌(但不能查看)。

https://www.example.com/callback#token=ACCESS_TOKEN
第四步：用户代理向资源服务器发出请求

用户代理依照重定向的指令，向资源服务器发出请求，但并不包含上一步中得到的授权令牌(#后面的部分)。用户代理将完整的重定向URI保存在本地。

第五步：资源服务器返回一个网页

资源服务器会返回一个网页(通常是一个HTML文件内嵌一段脚本)。这段内嵌的脚本(script)可以访问第三步中用户代理保存在本地的完整的重定向URI，并从中提取授权令牌。

第六步：用户代理提取授权令牌

用户代理执行上面提到的脚本，提取出授权令牌。然后将授权令牌传递给应用程序。

4.6 资源拥有者密码凭证模式(Resource Owner Password Credentials)

Password Credentials Flow
第一步：用户传递认证信息

用户将用户名和密码交给应用程序。

第二步：应用程序请求授权令牌
https://www.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID
第三步：授权服务器返回授权令牌

如果用户的认证信息得到验证，授权服务器将向应用程序返回授权令牌。

4.7 客户端模式(Client Credentials)

Client Credentials Flow
第一步：应用程序请求授权令牌
https://www.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
第二步：授权服务器返回授权令牌

授权服务器验证认证信息，向应用程序返回授权令牌。

4.7 更新令牌(Refresh Token)

https://www.example.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

总结与参考资料：

之后可能会写一个在Python中具体如何使用Twitter API或者Facebook API的实例，加深对OAuth的理解。
随着理解的深入，文章也会随时更新。

  1. An Introduction to OAuth 2
  2. 理解OAuth 2.0
  3. 帮你深入理解OAuth2.0协议
上一篇 下一篇

猜你喜欢

热点阅读