JWT和OAuth2.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音乐使用微信登录
    JWT和OAuth2.0

  • 示例2:口碑使用支付宝登录
    JWT和OAuth2.0文章来源地址https://www.toymoban.com/news/detail-415586.html

三、应用场景

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

到了这里,关于JWT和OAuth2.0的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 权限管理 springboot集成springSecurity Oauth2 JWT

    目录 一、SpringSeurity的基础操作 1、引入主要依赖 2、加密器 3、实现自定义登录逻辑 4、访问限制 5、自定义异常处理  6、通过注解的方式配置访问控制 二、Auth2认证方案 1、什么是Auth2认证 2、Oauth2最常用的授权模式  3、依赖引入 4、添加配置类 5、测试 6、存在到Redis里,后续

    2023年04月14日
    浏览(45)
  • Spring Gateway + Oauth2 + Jwt网关统一鉴权

    之前文章里说过,分布式系统的鉴权有两种方式,一是在网关进行统一的鉴权操作,二是在各个微服务里单独鉴权。 第二种方式比较常见,代码网上也是很多。今天主要是说第一种方式。 重要前提:需要收集各个接口的uri路径和所需权限列表的对应关系,并存入缓存。 服务

    2024年02月03日
    浏览(46)
  • Go语言的API安全: OAuth2与JWT

    在当今的互联网时代,API(应用程序接口)已经成为了应用程序之间的通信和数据共享的重要工具。然而,API安全也是一个重要的问题,因为不安全的API可能导致数据泄露、伪造和其他安全风险。为了解决这个问题,我们需要一种安全的方法来保护API,这就是OAuth2和JWT(JSON Web

    2024年03月12日
    浏览(42)
  • 微服务统一认证方案Spring Cloud OAuth2+JWT

    目录 前言 一、微服务架构下的统一认证场景 二、微服务架构下的统一认证思路 1.基于Session的认证方式 2.基于token的认证方式(主流) 三、OAuth2开放授权协议/标准 1.OAuth2介绍 2.OAuth2协议角色和流程 3.什么情况下需要使用OAuth2? 4.OAuth2的颁发Token授权方式 四、Spring Cloud OAuth2+JWT实现

    2023年04月09日
    浏览(71)
  • JWT VS OAuth2, 如何设计一个安全的API接口?

    Client Profile客户端描述 OAuth2框架也指定了集中客户端描述,用来表示应用程序的类型: Web应用 用户代理 原声应用 Authorization Grants认证授权 认证授权代表资源拥有者授权给客户端应用程序的一组权限,可以是下边几种形式: 授权码 隐式授权 资源拥有者密码证书 客户端证书

    2024年04月11日
    浏览(43)
  • Gateway+Springsecurity+OAuth2.0+JWT 实现分布式统一认证授权!

    目录 1. OAuth2.0授权服务 2. 资源服务 3. Gateway网关 4. 测试   在SpringSecurity+OAuth2.0 搭建认证中心和资源服务中心-CSDN博客 ​​​​​​ 基础上整合网关和JWT实现分布式统一认证授权。   大致流程如下: 1、客户端发出请求给网关获取令牌 2、网关收到请求,直接转发给授权服务

    2024年01月24日
    浏览(56)
  • 权限认证SpringCloud GateWay、SpringSecurity、OAuth2.0、JWT一网打尽!

    1.它是如何工作的? ​ 客户端向 Spring Cloud Gateway 发出请求。如果Gateway处理程序映射确定一个请求与路由相匹配,它将被发送到Gateway Web处理程序。这个处理程序通过一个特定于该请求的过滤器链来运行该请求。过滤器被虚线分割的原因是,过滤器可以在代理请求发送之前和

    2024年04月08日
    浏览(47)
  • SpringSecurity(二十四)--OAuth2:使用JWT和加密签名(下)非对称密钥加密

    由于上文对称密钥涉及到的内容比较多,所以这一节的非对称密钥加密拆开成这一节单独讲解。 所以大家尽量先阅读完上一章的内容后再浏览这一章内容会更好。 本节将实现OAuth2身份验证的一个示例,其中授权服务器和资源服务器会使用一个非对称密钥对来对令牌签名和验

    2024年02月16日
    浏览(50)
  • Spring Security OAuth 2.0 资源服务器— JWT

    目录 一、JWT的最小依赖 二、JWT的最基本配置 1、指定授权服务器 2、初始预期(Startup Expectations) 3、运行时预期(Runtime Expectations) 三、JWT认证是如何工作的 四、直接指定授权服务器 JWK Set Uri 五、提供 audiences 六、覆盖或取代启动自动配置 1、使用jwkSetUri() 2、使用decoder()

    2024年02月05日
    浏览(62)
  • SpringSecurity学习(八)OAuth2.0、授权服务器、资源服务器、JWT令牌的使用

    OAuth2是一个认证协议,SpringSecurity对OAuth2协议提供了响应的支持,开发者可以非常方便的使用OAuth2协议。 简介 四种授权模式 Spring Security OAuth2 GitHub授权登录 授权服务器与资源服务器 使用JWT OAuth是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密资源

    2024年02月02日
    浏览(60)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包