0


JWT和OAuth2.0

文章目录

前言

JWT和OAuth2.0没有可比性,是两个完全不同的东西。

JWT是一种认证协议,提供了一种用于发布接入令牌(Access Token),并对发布的签名接入令牌进行验证的方法。SSO私钥加密token。应用端公钥解密token,

OAuth2.0是一种授权框架,提供了一套详细的授权机制(指导)。用户或应用可以通过公开的或私有的设置,授权第三方应用访问特定资源。

一、JWT

1、JWT格式

一个JWT包含3个部分:

头部Header:可存放签名的类型

数据Payload:可存放用户数据和有效期,Payload的内容在接收者端是通过签名(Signature)来校验的。

签名Signature:使用密钥对Header和Payload数据进行加密生成签名。

JWT为了便于http传输,3个部分需再进行Base64Url编码后用

.

进行关联,格式如下:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

JWT真正的好处是让颁发JWT token的认证服务器和校验JWT token的应用服务器可以完全分开。

那签名是如何完成认证功能的呢,且看:

  1. 用户向认证服务器提交用户名和密码,认证服务器也可以和应用服务器部署在一起,但往往是独立的居多;
  2. 认证服务器校验用户名和密码组合,然后创建一个JWT token,token的Payload里面包含用户的身份信息,以及过期时间戳;
  3. 认证服务器使用密钥对Header和Payload进行签名,然后发送给客户浏览器;
  4. 浏览器获取到经过签名的JWT token,然后在之后的每个HTTP请求中附带着发送给应用服务器。经过签名的JWT就像一个临时的用户凭证,代替了用户名和密码组合,之后都是JWT token和应用服务器打交道了;
  5. 应用服务器检查JWT签名,确认Payload确实是由密钥拥有者签过名的;
  6. Payload身份信息代表了某个用户;
  7. 只有认证服务器拥有私钥,并且认证服务器只把token发给提供了正确密码的用户;
  8. 因此应用服务器可以认为这个token是由认证服务器颁发的也是安全的,因为该用户具有了正确的密码;
  9. 应用服务器继续完成HTTP请求,并认为这些请求确实属于这个用户;

2、签名和验签

对于JWT,签名方式有很多种,这里我们主要了解HS256和RS256。

HS256

HS256 使用同一个「secret_key」进行签名与验证(对称加密)。一旦 secret_key 泄漏,就毫无安全性可言了。

  • 如何使用哈希函数生成签名?

我们拿到Header、Payload外,还要加上一个密码,将这三个输入值一起哈希。输出结果是一个SHA-256 HMAC或者基于哈希的MAC。如果需要重复生成,则需要同时拥有Header、Payload和密码才可以。这也意味着,哈希函数的输出结果是一个数字签名,因为输出结果就表示了Payload是由拥有密码的角色生成并加签了的,没有其它方式可以生成这样的输出值了。

  • 如何校验JWT签名?

当我们的服务接收到HS256签名的JWT时,我们需要使用同样的密码才能校验并确认token里面的Payload是否有效。为了验证签名,我们只需要将JWT Header和Payload以及密码通过哈希函数生成结果。JWT的接收者需要拿到和发送者一样的密码值。如果我们得到的哈希结果和JWT第三部分的签名值是一致的,则说明有效,可以确认发送者确实和接收者拥有相同的密码值。

  • 公式如下:

签名Signature=Header+Payload+一个密码 进行SHA-256哈希;再进行Base64Url编码(主要方便url上传输)。

验签: Header+Payload+一个密码 进行SHA-256哈希;和JWT的签名Signature对比。

RS256

RS256 是使用 RSA 私钥进行签名,使用 RSA 公钥进行验证。相比HS256更加安全。

使用RS256我们同样需要生成一个MAC,其目的仍然是创建一个数字签名来证明一个JWT的有效性。只是在这种签名方式中,我们将创建token和校验token的能力分开,只有认证服务器具备创建的能力,而应用服务器,具备校验的能力。

这样,我们需要创建两个密钥而不是一个:

仍然需要一个私钥,不过这次它只能被认证服务器拥有,只用来签名JWT。
私钥只能用来签名JWT,不能用来校验它。
第二个密钥叫做公钥(public key),是应用服务器使用来校验JWT。
公钥可以用来校验JWT,但不能用来给JWT签名。
公钥一般不需要严密保管,因为即便黑客拿到了,也无法使用它来伪造签名。

  • 公式如下:

签名Signature=Header+Payload 进行SHA-256哈希,再使用私钥对哈希值进行签名;再进行Base64Url编码(主要方便url上传输)。

验签: Header+Payload进行SHA-256哈希;使用公钥签名Signature进行解密,解密后的值和前面哈希值对比。

RSA的两点基本原理

  1. 私钥加密,持有私钥或公钥才可以解密
  2. 公钥加密,持有私钥才可解密

RSA公钥、私钥加密的使用场景

公钥和私钥都可以用于加解密操作,用公钥加密的数据只能由对应的私钥解密,反之亦然。虽说两者都可用于加密,但是不同场景使用不同的密钥来加密,规则如下:

1、私钥用于签名、公钥用于验签

签名和加密作用不同,签名并不是为了保密,而是为了保证这个签名是由特定的某个人签名的,而不是被其它人伪造的签名,所以私钥的私有性就适合用在签名用途上。

私钥签名后,只能由对应的公钥解密,公钥又是公开的(很多人可持有),所以这些人拿着公钥来解密,解密成功后就能判断出是持有私钥的人做的签名,验证了身份合法性。

2、公钥用于加密、私钥用于解密,这才能起到加密作用

因为公钥是公开的,很多人可以持有公钥。若用私钥加密,那所有持有公钥的人都可以进行解密,这是不安全的!

若用公钥加密,那只能由私钥解密,而私钥是私有不公开的,只能由特定的私钥持有人解密,保证的数据的安全性。

二、OAuth2.0

OAuth2 有4种授权模式, 其中的access code授权码模式在实现时可以使用JWT生成code, 也可以不用. 它们之间没有必然的联系;

  • 示例1:QQ音乐使用微信登录在这里插入图片描述
  • 示例2:口碑使用支付宝登录在这里插入图片描述

三、应用场景

  1. OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)
  2. JWT是用在前后端分离, 需要简单的对后台API进行保护时使用.(前后端分离无session, 频繁传用户密码不安全)
标签: 服务器 网络 安全

本文转载自: https://blog.csdn.net/sssssooo/article/details/128509302
版权归原作者 百怪 所有, 如有侵权,请联系我们删除。

“JWT和OAuth2.0”的评论:

还没有评论