OAuth 2.0 协议原理与实现:token 生成策略

本文详细介绍了OAuth 2.0协议中的Bearer和MAC Type Access Token,包括它们的基本构成、请求与验证过程。重点讨论了Token的生成策略,强调了客户端与服务端在安全传输和验证中的角色。Token作为用户授权凭证,其生命周期管理和安全性对于数据保护至关重要。
摘要由CSDN通过智能技术生成

OAuth2.0 协议定义了授权详细流程,并最终以 token 的形式作为用户授权的凭证下发给客户端,客户端后续可以带着 token 去请求资源服务器,获取 token 权限范围内的用户资源。

对于 token 的描述,OAuth 2.0 协议只是一笔带过的说它是一个字符串,用于表示特定的权限、生命周期等,但是却没有明确阐述 token 的生成策略,以及如何去验证一个 token。RFC6749 对于 access token 的描述:

The client obtains an access token – a string denoting a specific scope, lifetime, and other access attributes.

协议不去详细阐述 token 的生成和验证过程,个人觉得是因为这一块各个业务都有自己的特点,无法完全做到抽象,并且在这一块去做详细的规定,其意义并不大。Token 本质上就是对用户授权这一操作在时间和权限范围两个维度上的一个表征,协议可以对 token 的传递和基本验证做相应规定,但是具体的一个 token 包含哪些元素,采用什么样的生成算法还是需要由自己去把握。

本文主要讲解自己对于 token 生成的一些思考,以及介绍两种类型:BEARER 和 MAC。

一. TOKEN 的基本构成

Token 表征了用户授权这一操作,授权服务器通过下发 token 来给客户端颁发获取用户受保护资源的资格,且不会因此而泄露用户的登录凭证信息。Token 对于客户端应该是非透明的,客户端只知道这是一个字符串,能够用它来获取用户的受保护资源,对于字符串内部所含的信息应该无从知晓,也不能通过其它方法去解密其中的信息。所以 token 应该是一类对称加密得到的字符串,并且只有授权服务器持有对称密钥,用于对生成的 token 进行加密和验证。

对于构成token的元素,各个业务都有自己的需求,不过仍然存在一些基本通用的元素,比如:

  1. clientId:客户端 ID,当前 token 隶属的客户端
  2. userId:用户的 ID,表示当前 token 来自哪个用户授权
  3. scope: 权限范围,该 token 允许换取的用户受保护资源范围
  4. issueTime: 下发时间,用于控制 token 的生命周期
  5. tokenType: token 的类型,不同类型可能会采用不同的验证措施

以上是个人根据经验总结的一些基础的 token 组成元素,具体业务还可以根据具体的需求添加一些其他的元素。

二. Bearer Type Access Token

BEARER 类型的 token 是在 RFC6750 中定义的一种 token 类型,OAuth 2.0 协议 RFC6749 对其也有所提及,算是对 RFC6749 的一个补充。BEARER 类型 token 是建立在 HTTP/1.1 版本之上的 token 类型,需要 TLS(Transport Layer Security) 提供安全支持,该协议主要规定了BEARER类型token的客户端请求和服务端验证的具体细节。

2.1 客户端请求

客户端在携带token请求用户的受保护资源时,需要保证token的安全性,以防止token被窃取或篡改,从而损害用户数据安全。BEARER类型token定义了三种token传递策略,客户端在传递token时必须使用其中的一种,且最多一种。

2.1.1 放在Authorization请求首部

Authorization首部说明

Authorization首部是由客户端发送,以向服务器回应自己的身份验证信息,客

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值