OAuth 2.0在WEB鉴权授权中的应用

宴西楼

已于 2023-05-23 11:18:54 修改

阅读量716

点赞数

文章标签：服务器网络设计模式

于 2023-05-23 11:14:04 首次发布

本文链接：https://blog.csdn.net/walkWayer/article/details/130615654

版权

背景

WEB鉴权授权机制的作用是保护系统资源的安全。认证授权机制可以防止未经授权的用户访问受保护的资源
鉴权是指验证用户身份的过程，即确认用户是否有权访问某个资源
授权是指在鉴权通过后，给予用户访问资源的权限

WEB鉴权授权机制的分类

BASIC认证：一种比较老的认证方式，也是安全系数比较低的认证方式
- 客户端通过明文（Base64编码格式）传输用户名和密码到服务端进行认证，通常需要配合HTTPS来保证信息传输的安全
基于cookie/session的认证：是WEB应用中常见的方式，实现成本也比较低
- 用户在客户端输入用户名和密码，提交表单
- 服务器验证用户名和密码，如果正确则生成一个session，并将session的id返回给客户端
- 客户端将session id保存在cookie中，下次请求时会自动带上cookie
- 服务器通过session id验证用户身份
基于OAuth 2.0协议的认证：一种基于Token的认证方式
- 用户打开客户端以后，客户端要求用户给予授权
- 用户同意给予客户端授权
- 客户端使用上一步获得的授权，向认证服务器申请令牌
- 认证服务器对客户端进行认证以后，确认无误，同意发放令牌
- 客户端使用令牌，向资源服务器申请获取资源
- 资源服务器确认令牌无误，同意向客户端开放资源

JWT和OAuth 2.0

JWT是一种认证协议，OAuth2.0是一种授权框架
OAuth2.0授权框架，依赖于Token，而JWT则是Token生成的一种方式

JWT

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式来表示声明，例如身份验证信息和授权信息。JWT通常用于验证用户身份，并为用户提供访问受保护资源的令牌
JWT由三部分组成：头部、载荷和签名。头部包含有关令牌类型和签名算法的信息。载荷包含声明，例如用户ID和过期时间。签名用于验证令牌的真实性

+------------------------+
|        Header          |
+------------------------+
|        Payload         |
+------------------------+
|        Signature       |
+------------------------+

OAuth 2.0

OAuth 2.0是一种授权机制，用于保护WEB资源并验证用户身份。OAuth 2.0用于授权第三方应用程序访问用户资源，例如用户存储在另一个服务上的照片、视频或文档

  +--------+                               +---------------+
  |        |--(A)- Authorization Request ->|   Resource    |
  |        |                               |     Owner     |
  |        |<-(B)-- Authorization Grant ---|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(C)-- Authorization Grant -->| Authorization |
  | Client |                               |     Server    |
  |        |<-(D)----- Access Token -------|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(E)----- Access Token ------>|    Resource   |
  |        |                               |     Server    |
  |        |<-(F)--- Protected Resource ---|               |
  +--------+                               +---------------+

(A) 用户打开客户端以后，客户端要求用户给予授权
(B) 用户同意给予客户端授权
© 客户端使用上一步获得的授权，向认证服务器申请令牌
(D) 认证服务器对客户端进行认证以后，确认无误，同意发放令牌
(E) 客户端使用令牌，向资源服务器申请获取资源
(F) 资源服务器确认令牌无误，同意向客户端开放资源

OAuth 2.0的优点：
- 简单易用：OAuth 2.0是一种简单而易于使用的授权协议，可以轻松地将其集成到现有的应用程序中
- 安全性：OAuth 2.0提供了一种安全的授权机制，可以保护用户的敏感信息
- 可扩展性：OAuth 2.0是一种可扩展的协议，可以根据需要添加新的授权流程和授权类型
- 支持多种客户端类型：OAuth 2.0支持多种客户端类型，包括WEB应用程序、桌面应用程序和移动应用程序
OAuth 2.0的缺点：
- 安全性问题：OAuth 2.0存在一些安全问题，例如CSRF攻击和重定向攻击
- 复杂性：OAuth 2.0是一种相对复杂的协议，需要开发人员具备一定的技术知识才能正确地实现它
- 隐私问题：OAuth 2.0可能会涉及用户隐私问题，例如用户授权访问其社交媒体账户时可能会泄露其个人信息
OAuth 2.0包括以下授权类型：
- 授权码模式（Authorization Code Grant）
- 隐式授权模式（Implicit Grant）
- 密码模式（Resource Owner Password Credentials Grant）
- 客户端模式（Client Credentials Grant）

OAuth 2.0使用

各个模式的使用规范

授权码模式（Authorization Code Grant）

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 WEB应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏
适用场景：目前主流的第三方验证都是采用这种模式

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

(A) 客户端访问用户代理，后者将前者重定向到授权服务器
(B) 授权服务器认证客户端信息，并确定用户是否给予客户端授权
© 用户给予授权，授权服务器将重定向事先指定的"重定向URI"（redirection URI），同时附上授权码
(D) 客户端收到授权码，附上早先的"重定向URI"，向授权服务器申请令牌(客户端后台进行，无感知)
(E) 授权服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access_token）和更新令牌（refresh_token）

隐式授权模式（Implicit Grant）

适用场景：仅需临时登录、纯前台的场景，安全性低

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

(A) 客户端重定向到授权服务器
(B) 授权服务器认证客户端信息，并确定用户是否给予客户端授权
© 如果用户授予访问权限，那么重定向事先指定的"重定向URI"（redirection URI），同时在URI的Hash部分中附上访问令牌（access_token）
(D) 浏览器通过redirection URI，向资源服务器发出请求，其中不包含上一步的Hash值
(E) 资源服务器返回一个页面，其中包含Hash值中的访问令牌
(F) 浏览器提取访问令牌
(G) 浏览器将访问令牌（access_token）传递给客户端

密码模式（Resource Owner Password Credentials Grant）

如果你高度信任某个应用，也允许用户把用户名和密码，直接告诉该应用。该应用使用密码，申请令牌，这种方式称为"密码式"（password）
在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而授权服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式
适用场景：公司搭建的授权服务器

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

(A) 用户向客户端提供用户名和密码
(B) 客户端将用户名和密码发给授权服务器，向后者请求令牌
© 授权服务器确认无误后，向客户端提供访问令牌

客户端模式（Client Credentials Grant）

适用场景：没有前端的命令行应用，通过命令行取得令牌

     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

(A) 客户端向认证服务器发起身份认证请求
(B) 认证服务器确认无误后，向客户端提供访问令牌

OAuth 2.0 token取得示例(以密码模式为例)

request
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w

response
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"
}

Token的使用

在业务请求中，附带上Token，一个会话使用一个Token，后面可以通过Token来管理会话

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer ${access_token}

以上实例，在请求头中，追加了Authorization属性，使用Token对业务请求进行了标记

Token的刷新

access_token是存在有效期的，通过refresh_token机制，可以实现永动机的效果

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

(A) 客户端向授权服务器发起请求
(B) 授权服务器在认证成功和取得授权后，返回access_token和refresh_token
© 客户端通过access_token向资源服务器发起请求
(D) 资源服务器验证access_token是否有效，如果有效，那么把相应资源返回给客户端
(E) 重复步骤©和步骤(D)直到access_token过期，如果过期了，那么跳转到步骤(G)
(F) 如果access_token过期，那么资源服务器返回非法token的错误消息
(G) 客户端使用refresh_token，向授权服务器发起请求
(H) 授权服务器对客户端进行认证和验证refresh_token值以后，如果有效，那么向客户端返回一个新的access_token和refresh_token

总结

OAuth2.0框架，提供了不同安全等级、不同使用场景的认证授权方式，可以根据不同的业务场景，灵活应用
同时，市面上，也有很多开源组织针对OAuth2.0框架进行了开发，可以很方便的把OAuth2.0框架引入到自主产品中，提升自主产品的安全性

参考文档：https://datatracker.ietf.org/doc/html/rfc6749

宴西楼

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
1
评论
OAuth 2.0在WEB鉴权授权中的应用

OAuth2.0框架，提供了不同安全等级、不同使用场景的认证授权方式，可以根据不同的业务场景，灵活应用同时，市面上，也有很多开源组织针对OAuth2.0框架进行了开发，可以很方便的把OAuth2.0框架引入到自主产品中，提升自主产品的安全性。
复制链接

扫一扫