2023年7月4日发(作者：)

OAuth2.0说明⽂档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的⽅式：（图⽚来源： ）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_idTrue创建应⽤时获得的App Keyresponse_typeTrue此值固定为“code”授权后要回调的URI，即接收Authorization Code的URI, 其redirect_uriTrue值可以是“oob”。 ⾮“oob”值的redirect_uri所在域名必须与开发者注册应⽤时所提供的回调地址的域名相匹配以空格分隔的权限列表，若不传递此参数，代表请求默认的scopeFalsebasic权限。（⽬前只有basic权限）hash，⽤于预防CSRF，⽤于保持请求和回调的状态，授权stateFalse服务器在重定向到“redirect_uri”时，会在Query Parameter中原样回传该参数/authorize?client_id=ABCDEFGHIJKLMNOP&response_type=code&redirect_uri=/oauth_redirect&scope=basic&state=mytest如果⽤户在此页⾯同意授权，则将重定向⽤户浏览器到指定的“redirect_uri”，并附带上表⽰授权服务所分配的Authorization Code的code参数（假设为““），以及state参数（如果有），验证通过后，认证服务器将重定向⽤户浏览器到“/oauth_redirect?state=mytest&code=”说明：每⼀个Authorization Code的有效期为60秒（可根据需求调长⼀些，但原则上应尽可能短），并且只能使⽤⼀次，再次使⽤将⽆效。

通过Authorization Code获取Access Token通过上⾯第⼀步获得Authorization Code后，便可以⽤其向认证服务器换取⼀个Access Token。参数名必选grant_typeTruecodeTrueclient_idTrueclient_secretTrue介绍此值固定为“authorization_code”通过上⾯第⼀步所获得的Authorization Code创建应⽤时获得的App Key应⽤的App Secretredirect_uri所在域名必须与开发者注册应⽤时所提供的回调redirect_uriTrue地址的域名匹配/access_token?grant_type=authorization_code&code=&client_id=ABCDEFGHIJKLMNOP&client_&redirect_uri=/oauth_redirect

若参数⽆误，服务器将返回⼀段JSON⽂本，包含以下参数：参数名必选介绍access_tokenTrue令牌类型获取的Access Token“bearer”或“mac”，暂⽆很明确的说明，通常是token_typeFalse令牌类型“bearer”或“mac”，暂⽆很明确的说明，通常是brearer或省略expires_inTrueAccess Token的有效期，以秒为单位refresh_tokenFalse⽤于刷新Access Token 的 Refresh TokenAccess Token最终的访问范围，即⽤户实际授予的权限列scopeFalse表，⽤户在授权页⾯时，有可能会取消掉某些请求的权限，通常只作或只有登录认证的话，可忽略token_typeFalse⽰例：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天内登录，应⽤就可以使⽤RefreshToken获得新的Access Token。

要使⽤Refresh Token获得新的Access Token，需要应⽤在其服务端发送请求（推荐⽤POST⽅法）到开放平台OAuth2.0授权服务的以下地址： “/access_token”，并带上以下参数：参数名必选grant_typeTruerefresh_tokenTrueclient_idTrueclient_secretTruescope介绍必须为“refresh_token”⽤于刷新Access Token⽤的Refresh Token创建应⽤时获得的App Key应⽤的App Secret以空格分隔的权限列表，若不传递此参数，代表请求默认的basic权限。注：通过Refresh Token刷新AccessFalseToken时所要求的scope权限范围必须⼩于等于上次获取Access Token时授予的权限范围⽰例：/access_token?grant_type=refresh_token&refresh_token=qwertyuiop&client_id=ABCDEFGHIJKLMNOP&client_&scope=basic若请求成功服务器将返回⼀段JSON⽂本，包含以下参数⽰例：Content-Type: application/json{ "access_token":"uuvvwwxxyyzz","expires_in":"120","scope":"basic","refresh_token":" qwertyuiop"}

2、使⽤access_token调⽤API获取access_token以后，就可以使⽤access_token调⽤API接⼝。调⽤API的URL“/json”传递需要的参数，参数的详细介绍请参照以上描述例：/json?access_token=uuvvwwxxyyzz