OAuth2.0协议

·  阅读 59

OAuth 2.0 是行业标准的授权协议,OAuth 2.0 专注于客户端开发人员的简单性,同时为 Web 应用程序、桌面应用程序、移动电话和直播间设备提供特定的授权流程。

一、角色

OAuth2.0定义了4个角色: 资源所有者(resource owner):能够授予对受保护资源的访问权限的实体。当资源所有者是一个人时,它被称为终端用户 资源服务器(resource server):托管受保护资源的服务器,能够使用access token接收和响应受保护资源的请求 客户端(client):代表资源所有者并经其授权发出受保护资源请求的应用程序 授权服务器(authorization server):在成功验证资源所有者后并向客户端颁发access token

角色之间的交互如下:

411EC54C-778E-4231-8C9E-2377D077497C.png

流程不复杂,授权的目的是获取到access token,通过access token来访问服务器资源

二、授予授权

授予授权代表资源所有者通过客户端获取一个access token的凭证,OAuth2.0定义了4钟授权类型:授权码(authorization code),隐式授权(implicit),资源所有者密码凭证(resource owner password credentials),客户端凭证(client credentials)

授权码:授权码是通过授权服务器获取的,作为客户端和资源所有者之间的中介,客户端通过授权码让资源所有者访问授权服务器

隐式授权:隐式授权是一种简化的授权码流程,主要是给浏览器使用的

密码凭证:比如使用账号和密码来获取access token

客户端凭证:仅限在客户端控制下的受保护资源时,或对先前经授权安排的受保护资源服务器时,可以通过客户端凭证授予授权

三、Access Token

OAuth访问令牌是OAuth 客户端用来向资源服务器发出请求的字符串,access token没有固定格式,可以是bearer tokens或者 sender-constrained token,sender-constrained token要求客户端以某种方式证明拥有私钥才能使用访问令牌,这样access token本身就无法使用,bearer tokens是一串不透明的字符串,一些服务器会使用一串16进制的字符来制作access token。

发布access token

如果access token请求是合法且允许授权,那么就可以发布access token,一个成功的响应(status=200)如下:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache


{
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
}

复制代码

access_token:必须 token_type:token的类型,"bearer" token或者是"mac” token,datatracker.ietf.org/doc/html/rf… expires_in:建议,有效期,如3600表示access token可存活一小时 refresh_token:可选 scope:可选,由授权服务器定义的字符串,如果客户端在请求授权时省略了scope参数,授权服务器必须要么 使用预定义的默认值处理请求,要么使请求失败,指示无效范围。如果客户端传了scope参数,授权服务器应该记录其范围要求和默认值。

失败的响应如下:

HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
       "error":"invalid_request"
}

复制代码

error还可以描述:invalid_client、invalid_grant、unauthorized_client、unsupported_grant_type、invalid_scope

四、Refresh Token

Refresh Token主要用来刷新access token,access token一般会有一个有效期,Refresh Token也会有一个有效期,一般前者的有效期是小于后者的有效期的,这样如果access token过期了,我们可以使用Refresh Token重新获取新的access token。刷新过程如下:

524B3315-3EA0-44D3-B1A9-53741F68B467.png

(1) 客户端通过与授权服务器进行身份验证并提供授权许可来请求access token。 (2) 授权服务器对客户端进行身份验证并验证授予授权,如果有效,则返回access token和一个refresh token。 (3) 客户端通过提供access token向资源服务器发出受保护的资源请求。 (4) 资源服务器验证access token,如果有效,则为请求提供服务。 (5) 重复步骤 (3) 和 (5) 直到access token过期。如果客户端知道access token过期,则跳到步骤(7);否则,它会发出另一个受保护的资源请求。 (6) 由于access token无效,资源服务器返回无效token错误。 (7) 客户端通过向授权服务器进行身份验证并提供refresh token来请求新的access token。客户端身份验证要求基于客户端类型和授权服务器策略。 (8) 授权服务器对客户端进行身份验证并验证refresh token,如果有效,则发出新的access token(以及,optional refresh token)。

五、Authorization Code授权

Authorization Code授权类型既可以获取access token,也可以获取refresh token

由于这是基于重定向的流程,因此客户端必须能够在资源拥有者的代理(通常是web浏览器)和来自授权服务器的请求之间交互,也就是必须能够充当中介的作用。

C9D761B2-031F-4143-AB86-D2B3570CF1D8.png

(1) 客户端通过将资源所有者的用户代理定向到授权端点来启动流程。客户端包括其标识符、请求的范围、本地状态和授予(或拒绝)访问权限,授权服务器会将用户代理发送回 URI

(2) 授权服务器验证资源所有者(通过用户代理)并确定资源所有者是允许还是拒绝客户端的访问请求。

(3) 假设资源所有者授予访问权限,授权服务器使用之前提供的重定向 URI,将用户代理重定向回客户端。重定向 URI,包括授权代码和客户端之前提供的任何本地状态。

(4) 客户端通过包含在上一步中收到的授权码,从授权服务器的令牌端点请求access token。发出请求时,客户端向授权服务器进行身份验证。客户端包含用于获取授权的重定向 URI验证码。

(5) 授权服务器对客户端进行身份验证,验证授权码,并确保接收到的重定向 URI与步骤 (3)中用于重定向客户端的 URI 匹配。如果有效,授权服务器将返回access token和optional refresh token。

六、访问受保护资源

客户端通过access token访问受保护资源,而资源服务器必须验证access token的有效期和所覆盖的资源范围。

七、飞书的移动应用登录-OAuth2.0实现

453EEF13-254E-4CDF-A942-E4AF11F6C0AF.png

第一步:获取 code

第二步:获取 access_token

第三步:获取用户身份信息

第四步:刷新已过期的 access_token

参考:

1.oauth.net/2/ 2.open.feishu.cn/document/uA…

分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改