OAuth2.0说明文档

最新推荐文章于 2023-12-23 19:50:27 发布

weixin_34128839

最新推荐文章于 2023-12-23 19:50:27 发布

阅读量287

点赞数

文章标签： json javascript 嵌入式 ViewUI

原文链接：http://www.cnblogs.com/skey_chen/p/5749288.html

版权

OAuth2.0说明文档

1、OAuth 2.0 简介

OAuth为应用提供了一种访问受保护资源的方法。在应用访问受保护资源之前，它必须先从资源拥有者处获取授权（访问许可），然后用访问许可交换访问令牌（代表许可的作用域、持续时间和其它属性）。应用通过向资源服务器出示访问令牌来访问受保护资源。

下图中的名词说明

Resource Owner：用户

User-Agent：浏览器

Client：应用服务器

Authorization Server：认证服务器（用户信息存放服务的认证服务器）

Resource Server：资源服务器（用户真正信息存放的服务器，需要通过access_token进行访问）

Web-Hosted Client Resource：web托管的客户端资源（这个确切的说，我也不知道叫啥才适合）

OAuth2.0服务支持以下5种获取Access Token的方式：（图片来源：OAuth2.0协议草案）

1.1、APP密钥模式（Client Credentials Flow）

直接使用app密钥，不另作说明

1.2、Resource Owner Password Credentials Flow

直接使用用户密码，不另作说明

1.3、Authorization Code Flow

授权码模式

流程简单表述为，当用户访问应用服务器

(A)应用服务器返回带有授权信息的重定向链接，浏览器拿到链接，转为访问认证服务器（见下面：获取Authorization Code）

(B)认证服务器提供界面给用户进行确认授权，用户确认授权

(C)用户确认授权后，认证服务器返回带有code的重定向链接，浏览器拿到链接，转为访问应用服务器

(D)应用服务器拿到code，访问认证服务器（见下面：通过Authorization Code获取Access Token）

(E)认证服务器验证后，返回access_token给应用服务器

授权码是应用弹出窗口，并将用户引导到授权服务器，传入标识符、请求作用域、本地状态，和一个重定向URI。授权服务器验证用户，获得授权，然后用重定向URI引导回应用，并传回授权码给应用。因为终端用户只在授权服务器上进行验证，所以终端用户的用户名和密码从来不用分享给应用。

获取Authorization Code

参数名	必选	介绍
client_id	True	创建应用时获得的App Key
response_type	True	此值固定为“code”
redirect_uri	True	授权后要回调的URI，即接收Authorization Code的URI, 其值可以是“oob”。非“oob”值的redirect_uri所在域名必须与开发者注册应用时所提供的回调地址的域名相匹配
scope	False	以空格分隔的权限列表，若不传递此参数，代表请求默认的basic权限。（目前只有basic权限）
state	False	hash，用于预防CSRF，用于保持请求和回调的状态，授权服务器在重定向到“redirect_uri”时，会在Query Parameter中原样回传该参数

/authorize?client_id=ABCDEFGHIJKLMNOP&response_type=code&redirect_uri=http://www.example.com/oauth_redirect&scope=basic&state=mytest

如果用户在此页面同意授权，则将重定向用户浏览器到指定的“redirect_uri”，并附带上表示授权服务所分配的Authorization Code的code参数（假设为“0987654321“），以及state参数（如果有），验证通过后，认证服务器将重定向用户浏览器到“http://www.example.com/oauth_redirect?state=mytest&code=0987654321”

说明：每一个Authorization Code的有效期为60秒（可根据需求调长一些，但原则上应尽可能短），并且只能使用一次，再次使用将无效。

通过Authorization Code获取Access Token

通过上面第一步获得Authorization Code后，便可以用其向认证服务器换取一个Access Token。

参数名	必选	介绍
grant_type	True	此值固定为“authorization_code”
code	True	通过上面第一步所获得的Authorization Code
client_id	True	创建应用时获得的App Key
client_secret	True	应用的App Secret
redirect_uri	True	redirect_uri所在域名必须与开发者注册应用时所提供的回调地址的域名匹配

/access_token?grant_type=authorization_code&code=0987654321&client_id=ABCDEFGHIJKLMNOP&client_secret=abcdefg...&redirect_uri=http://www.example.com/oauth_redirect

若参数无误，服务器将返回一段JSON文本，包含以下参数：

参数名	必选	介绍
access_token	True	获取的Access Token
token_type	False	令牌类型“bearer”或“mac”，暂无很明确的说明，通常是brearer或省略
expires_in	True	Access Token的有效期，以秒为单位
refresh_token	False	用于刷新Access Token 的 Refresh Token
scope	False	Access Token最终的访问范围，即用户实际授予的权限列表，用户在授权页面时，有可能会取消掉某些请求的权限，通常只作或只有登录认证的话，可忽略

示例：Content-Type: application/json

{"access_token":"uuvvwwxxyyzz","expires_in":"3600", "scope":"basic","refresh_token":"qwertyuiop"}

1.4、Implicit Grant Flow

简化模式，该模式下，通常client和user-agent是在一起的，如手机app等

流程简单表述为，当用户访问应用服务

(A)应用服务返回带有授权信息的重定向链接，浏览器拿到链接，转为访问认证服务器

(B)认证服务器提供界面给用户进行确认授权，用户确认授权

(C)假设资源所有者授予访问权限，则认证服务器返回带有获取access_token的令牌的链接

(D)浏览器链接重定向到一个web客户端资源，访问资源服务器

(E)返回一个网页（通常是一个嵌入式脚本的HTML文档）

(F)浏览器从脚本中提取access_token（包括其他参数）

(G)浏览器带着access_token重定向到应用服务器，应用服务器到浏览器传来的access_token

采用Implicit Grant方式获取Access Token的授权验证流程又被称为User-Agent Flow，适用于所有无Server端配合的应用（由于应用往往位于一个User Agent里，如浏览器里面，因此这类应用在某些平台下又被称为Client-Side Application），如手机/桌面客户端程序、浏览器插件等，以及基于JavaScript等脚本语言实现的应用。

1.5、Refreshing an Expired Access Token

令牌刷新方式，适用于所有有Server端配合的应用，其实就是更新access_token

获取Access Token，都会拿到有效期为14天的Refresh Token，和2分钟有效期的Access Token。对于这些应用，只要用户在14天内登录，应用就可以使用Refresh Token获得新的Access Token。

要使用Refresh Token获得新的Access Token，需要应用在其服务端发送请求（推荐用POST方法）到开放平台OAuth2.0授权服务的以下地址： “/access_token”，并带上以下参数：

参数名	必选	介绍
grant_type	True	必须为“refresh_token”
refresh_token	True	用于刷新Access Token用的Refresh Token
client_id	True	创建应用时获得的App Key
client_secret	True	应用的App Secret
scope	False	以空格分隔的权限列表，若不传递此参数，代表请求默认的basic权限。注：通过Refresh Token刷新Access Token时所要求的scope权限范围必须小于等于上次获取Access Token时授予的权限范围