对比三种认证方式：传统token认证，jwt认证，oauth认证

慢！有杀气

已于 2023-12-11 15:18:01 修改

阅读量2.2k

点赞数 1

分类专栏： MYLinux 文章标签：认证

于 2023-12-11 15:15:42 首次发布

本文链接：https://blog.csdn.net/qq1319713925/article/details/134922508

版权

MYLinux 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1. Token基本原理

1、客户端使用用户名跟密码请求登录；

2、服务端收到请求，去验证用户名与密码；

3、验证成功，服务端会签发一个Token（也就是随机生成一个字符串）保存到(Session,redis,mysql…)中，然后再把这个 Token 发送给客户端；

4、客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；

5、客户端每次向服务端请求资源的时候需要带着服务端签发的 Token；

6、服务端收到请求，验证密客户端请求里面带着的 Token和服务器中保存的Token进行对比校验，如果验证成功，就继续执行客户端请求的业务逻辑，否则就是验证失败报错返回给客户端；

1.1 token示例

传统的token认证，这个token就是一个随机字符串。服务端收到后，直接拿去查库比对，确认用户信息。

2. jwt认证原理

1、客户端使用用户名跟密码请求登录；

2、服务端收到请求，去验证用户名与密码；

3、验证成功，服务端会在配置文件中配置一个jwt的secret。根据secret签发一个JwtToken,无须存储到服务器，直接再把这个JwtToken发送给客户端；

4、客户端收到JwtToken以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里；

5、客户端每次向服务端请求资源的时候需要带着服务端签发的JwtToken；

6、服务端收到请求，使用jwt的secret验证密客户端请求里面带着的 JwtToken，如果验证成功，就继续执行客户端请求的业务逻辑，否则就是验证失败报错返回给客户端；

2.2 jwt token示例

这个服务端和客户端一直传输的jwttoken长啥样呢？长下面这样。

就是一个字符串，分三个部分，通过.连接起来。

Header.Payload.Signature

拆解如下：

base64UrlEncode(header) + . + base64UrlEncode(payload) + . + 签名（HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)）

2.2.1 header

# JWT头部分是一个描述JWT元数据的JSON对象，通常如下所示。
{
   "alg": "HS256",
   "typ": "JWT"
}
# 1）alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256）；
# 2）typ属性表示令牌的类型，JWT令牌统一写为JWT。
# 3）最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。

2.2.2 Payload

#1、有效载荷部分，是JWT的主体内容部分，也是一个JSON对象，包含需要传递的数据。 JWT指定七个默认 字段供选择。
'''
iss：发行人
exp：到期时间
sub：主题
aud：用户
nbf：在此之前不可用
iat：发布时间
jti：JWT
ID用于标识该JWT
'''

#2、除以上默认字段外，我们还可以自定义私有字段，如下例：
{
"sub": "1234567890",
"name": "chongchong",
"admin": true
}
#3、注意 默认情况下JWT是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防 止信息泄露。
JSON对象也使用Base64 URL算法转换为字符串保存

2.2.3 签名哈希

签名=HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)

# 1.签名哈希部分是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。
# 2.首先，需要指定一个密码（secret），该密码仅仅为保存在服务器中，并且不能向用户公开。
# 3.然后，使用标头中指定的签名算法（默认情况下为HMAC SHA256）根据以下公式生成签名。
# 4.HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)
# 5.在计算出签名哈希后，JWT头，有效载荷和签名哈希的三个部分组合成一个字符串，每个部分用"."分 隔，就构成整个JWT对象

这样一个结构，服务端拿到这个jwt token后，结合自己的secret 对前面两部分进行签名，再和jwt token中的签名进行对比，就能直接判断这个jwt token的真实性。而不再像传统认证那样去查库才能认证了。

3oauth认证原理

OAuth（开放授权）是一个开放标准，用于授权一个应用程序或服务访问用户在另一个应用程序中的资源，而无需提供用户名和密码。这使得用户可以安全地分享他们的数据资源，同时保持对其数据的控制。OAuth 2.0在现代互联网应用中被广泛使用，例如，你可以使用你的Google账号登录到其他网站，这就是OAuth的一种应用。

简单来说：OAuth 2.0 是目前最流行的授权机制，用来授权第三方应用，获取用户数据。

token&jwt 都是系统自己的用户的认证方式。

oauth 是系统允许其他系统的用户来登录自己的系统。比如很多系统需要微信授权登录，实际上就是用户用微信的用户信息，登录自己的系统。作为自己系统的用户。

允许其他用户登录自己系统，还有单点登录。

单点登录，登录一个系统后，自动登录其他系统。

OAuth 2.0广泛应用于各种场景，以下是一些常见的应用场景：

社交登录：用户可以使用他们的社交媒体帐户登录到其他应用程序，例如使用Google或Facebook登录。
API访问：开发人员可以使用OAuth 2.0来访问第三方API，例如使用GitHub API或Twitter API。
单点登录：用户可以使用一个身份验证提供商登录到多个相关的应用程序，而无需多次输入凭证。
授权访问：应用程序可以请求用户授权访问其资源，例如Google云存储或Dropbox。
移动应用授权：移动应用程序可以安全地请求访问用户数据，如照片、联系人或位置信息。

3.1认证原理

OAuth 的核心就是向第三方应用颁发令牌。

而oauth定义了获得令牌的四种授权方式：

授权码（authorization-code）
隐藏式（implicit）
密码式（password）：
客户端凭证（client credentials）

最常用的是授权码模式。

3.1.1. 授权码模式

用户访问想要访问a系统，a系统上有可以用b系统（微信）来登录。用户选择b系统登录，跳转到b系统去授权，用户点击同意授权，接着会返回到b系统中，拿到授权码。这时候用户继续访问a系统。a系统用这个授权码访问b系统（微信）。微信判断这个授权码正确，然后派发token。返回正确。a系统则可以用这个token访问用户在B系统（微信）上的资源。