.Net Core授权认证方案JWT(JSON Web Token)初探

一、前言

现在越来越多的项目或多或少会用到JWT,为什么会出现使用JWT这样的场景的呢?

假设现在有一个APP,后台是分布式系统。APP的首页模块部署在上海机房的服务器上,子页面模块部署在深圳机房的服务器上。此时你从首页登录了该APP,然后跳转到子页面模块。session在两个机房之间不能同步,用户是否需要重新登录?

传统的方式(cookie+session)需要重新登录,用户体验不好。session共享(在多台物理机之间传输和复制session)方式对网络IO的压力大,延迟太长,用户体验也不好。

说到这大家可能会想到,用服务器的session_id存储到cookies中也能做到,为什么非要用token呢?网上有许多文章来比较token和session的优缺点,其实,开发web应用的话用哪种都行。但如果是开发api接口,前后端分离,最好使用token,为什么这么说呢,因为session+cookies是基于web的。但是针对 api接口,可能会考虑到移动端,app是没有cookies和session的。

Session方式存储用户信息的最大问题在于要占用大量服务器内存,增加服务器的开销。

而JWT方式将用户状态分散到了客户端中,可以明显减轻服务端的内存压力。Session的状态是存储在服务器端,客户端只有session id;而Token的状态是存储在客户端

二、原理

JSON Web Token(缩写 JWT)

JWT 的原理是,服务器认证以后,生成一个 JSON 对象,发回给用户,以后,用户与服务端通信的时候,都要发回这个 JSON 对象。

服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据,服务器在生成这个对象的时候,会加上签名。

服务器就不保存任何 session 数据了,也就是说,服务器变成无状态了,从而比较容易实现扩展。

三、组合

JWT 的三个部分依次是:Header(头部)、Payload(负载)、Signature(签名)

写成一行,就是下面的样子。

Header.Payload.Signature

1、Header头部

header典型的由两部分组成:token的类型(“JWT”)和算法名称(比如:HMAC SHA256或者RSA等等)

{
    "alg": "HS256", //alg属性表示签名的算法(algorithm),默认是 HMAC SHA256(写成 HS256)
    "typ": "JWT"   //typ属性表示这个令牌(token)的类型(type)
}

然后用Base64对这个JSON编码就得到JWT的第一部分

2、Payload负载

JWT的第二部分是payload,它包含声明(要求)。声明是关于实体(通常是用户)和其他数据的声明

JWT 规定了7个官方字段

  • iss (issuer):签发人
  • exp (expiration time):过期时间
  • sub (subject):主题
  • aud (audience):受众
  • nbf (Not Before):生效时间
  • iat (Issued At):签发时间
  • jti (JWT ID):编号

除了官方字段,你还可以在这个部分定义私有字段,下面就是一个例子

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

注意,不要在JWT的payload或header中放置敏感信息,除非它们是加密的

3、Signature签名

Signature 部分是对前两部分的签名,防止数据篡改。

签名是用于验证消息在传递过程中有没有被更改,并且,对于使用私钥签名的token,它还可以验证JWT的发送方是否为它所称的发送方。

为了得到签名部分,你必须有编码过的header、编码过的payload、一个秘钥。签名算法是header中指定的那个,然对它们签名即可。按照下面的公式产生签名。

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

算出签名以后,把 Header、Payload、Signature 三个部分拼成一个字符串,每个部分之间用"点"(.)分隔,就可以返回给用户。

四、开始

1、客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以储存在 localStorage。

此后,客户端每次与服务器通信,都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送,但是这样不能跨域,所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

2、JWT 就放在 POST 请求的数据体里面,那么跨源资源共享(CORS)将不会成为问题,因为它不使用cookie。

  • 应用(或者客户端)向授权服务器请求授权。例如,如果用授权码流程的话,就是/oauth/authorize
  • 当授权被许可以后,授权服务器返回一个access token给应用
  • 应用使用access token访问受保护的资源(比如:API)

五、特点

1.JWT 默认是不加密,但也是可以加密的。生成原始 Token 以后,可以用密钥再加密一次。

2.JWT 不加密的情况下,不能将秘密数据写入 JWT。

3.JWT 的最大缺点是,由于服务器不保存 session 状态,因此无法在使用过程中废止某个 token,或者更改 token 的权限。也就是说,一旦 JWT 签发了,在到期之前就会始终有效,除非服务器部署额外的逻辑。

4.JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。

注意:

JWT 是 JSON 格式的被加密了的字符串

JWT 的核心是密钥,就是 JSON 数据。这是你关心的,并希望安全传递出去的数据。JWT 如何做到这一点,并使你信任它,就是加密签名。

被篡改之后

六、总结

参考官方文档:JSON Web Tokens

到此这篇关于.Net Core授权认证方案JWT的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • ASP.NET Core使用JWT自定义角色并实现策略授权需要的接口

    ① 存储角色/用户所能访问的 API 例如 使用 List<ApiPermission> 存储角色的授权 API 列表. 可有可无. 可以把授权访问的 API 存放到 Token 中,Token 也可以只存放角色信息和用户身份信息. /// <summary> /// API /// </summary> public class ApiPermission { /// <summary> /// API名称 /// </summary> pub

  • 详解ASP.NET Core Web Api之JWT刷新Token

    前言 如题,本节我们进入JWT最后一节内容,JWT本质上就是从身份认证服务器获取访问令牌,继而对于用户后续可访问受保护资源,但是关键问题是:访问令牌的生命周期到底设置成多久呢?见过一些使用JWT的童鞋会将JWT过期时间设置成很长,有的几个小时,有的一天,有的甚至一个月,这么做当然存在问题,如果被恶意获得访问令牌,那么可在整个生命周期中使用访问令牌,也就是说存在冒充用户身份,此时身份认证服务器当然也就是始终信任该冒牌访问令牌,若要使得冒牌访问令牌无效,唯一的方案则是修改密钥,但是如果我们这么做了,

  • ASP.NET Core 6.0 添加 JWT 认证和授权功能

    目录 序言 相关名词 认证(Authentication) 基本步骤 1 安装 Nuget 包 2 准备配置信息 3 添加服务 4 调用中间件 5 JwtHelper 类实现 6 控制器配置 7 测试调用 授权(Authorization) 相关标签(Attribute) 授权方式 1 Policy(策略) 2 Role(角色) 3 Scheme(方案) 3 定义权限项 4 实现 Requirement 5 实现授权处理程序 Handler 6 添加授权处理程序 7 添加授权策略 8 控制器配置

  • .Net Core实现JWT授权认证

    关于JWT的基本概念,如果有不清晰的同学,请点击这里,就不在这里赘述了.接下来聊聊JWT是怎么发挥作用的. 第一,安装nuget包 Microsoft.AspNetCore.Authentication.JwtBearer 第二,配置[Startup] 首先是[ConfigureServices]方法,下面要写一大堆进去 services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(x => {

  • .net core api接口JWT方式认证Token

    一.项目>管理Nuget包 安装 二..appsettings.json添加 "JWT": { "Secret": "~!@#$%^&*()_+qwertyuiopasldkh[o51485421ajshk^%*)kasd", // 密钥 "Issuer": "kfjdhf", // 颁发者 "Audience": "kfjdhf", // 接收者 //

  • .Net Core官方JWT授权验证的全过程

    什么是JWT? JSON Web令牌(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑且自包含的方式,用于在各方之间安全地传输信息作为JSON对象.由于此信息是经过数字签名的,因此可以被验证和信任.可以使用秘密(使用HMAC算法)或使用RSA或ECDSA的公钥/私钥对对JWT进行签名. 尽管可以对JWT进行加密以提供双方之间的保密性,但我们将重点关注已签名的令牌.签名的令牌可以验证其中包含的声明的完整性,而加密的令牌则将这些声明隐藏在其他方的面前.当使用公钥/私钥对对令牌进行签名时,

  • .NET 6实现基于JWT的Identity功能方法详解

    目录 需求 目标 原理与思路 实现 引入Identity组件 添加认证服务 使用JWT认证和定义授权方式 引入认证授权中间件 添加JWT配置 增加认证用户Model 实现认证服务CreateToken方法 添加认证接口 保护API资源 验证 验证1: 验证直接访问创建TodoList接口 验证2: 获取Token 验证3: 携带Token访问创建TodoList接口 验证4: 更换Policy 一点扩展 总结 参考资料 需求 在.NET Web API开发中还有一个很重要的需求是关于身份认证和授

  • .net使用jwt进行身份认证的流程记录

    目录 什么是身份认证和鉴权 jwt工作流程 token是如何生成的 jwt三部分 jwt是如何保证数据不会被篡改的 .net webapi 的 demo 总结 什么是身份认证和鉴权 举个例子 假设有这么一个小区,小区只允许持有通行证的人进入,陌生人如果想直接进入小区会被保安拦住,他必须先办理通行证才会被允许进入 类比身份认证和鉴权体系 一个人要访问我的一个机密的接口,我首先需要知道你是谁,搞清楚你是谁的过程就是身份认证,如果我搞不清楚你是谁,那你就是陌生人,身份认证失败. 身份认证通过,并不一定

  • ASP.NET Core 实现自动刷新JWT Token

    目录 原理 实现 结论 前言: 为了安全性考虑,我们可以设置JWT Token较短的过期时间,但是这样会导致客户端频繁地跳到登录界面,用户体验不好. 正常解决办法是增加​​refresh_token​​,客户端使用refresh_token去主动刷新JWT Token. 这里介绍一种变通的方式,自动刷新JWT Token. 原理 我们读取每个请求的​​Authorization​​头,获得当前请求的JWT Token. 检查当前token的过期时间,如果在30分钟以内,那么我们就生成一个具有新过

  • .Net Core授权认证方案JWT(JSON Web Token)初探

    一.前言 现在越来越多的项目或多或少会用到JWT,为什么会出现使用JWT这样的场景的呢? 假设现在有一个APP,后台是分布式系统.APP的首页模块部署在上海机房的服务器上,子页面模块部署在深圳机房的服务器上.此时你从首页登录了该APP,然后跳转到子页面模块.session在两个机房之间不能同步,用户是否需要重新登录? 传统的方式(cookie+session)需要重新登录,用户体验不好.session共享(在多台物理机之间传输和复制session)方式对网络IO的压力大,延迟太长,用户体验也不好

  • php实现JWT(json web token)鉴权实例详解

    JWT是什么 JWT是json web token缩写.它将用户信息加密到token里,服务器不保存任何用户信息.服务器通过使用保存的密钥验证token的正确性,只要正确即通过验证.基于token的身份验证可以替代传统的cookie+session身份验证方法. JWT由三个部分组成:header.payload.signature 以下示例以JWT官网为例 header部分: { "alg": "HS256", "typ": "JWT

  • JSON Web Token(JWT)原理入门教程详解

    目录 一.跨域认证的问题 二.JWT 的原理 三.JWT 的数据结构 3.1 Header 3.2 Payload 3.3 Signature 3.4 Base64URL 四.JWT 的使用方式 五.JWT 的几个特点 六.参考链接 一.跨域认证的问题 互联网服务离不开用户认证.一般流程是下面这样. 1.用户向服务器发送用户名和密码. 2.服务器验证通过后,在当前对话(session)里面保存相关数据,比如用户角色.登录时间等等. 3.服务器向用户返回一个 session_id,写入用户的 Co

  • 详解JSON Web Token 入门教程

    JSON Web Token(缩写 JWT)是目前最流行的跨域认证解决方案,本文介绍它的原理和用法. 一.跨域认证的问题 互联网服务离不开用户认证.一般流程是下面这样. 1.用户向服务器发送用户名和密码. 2.服务器验证通过后,在当前对话(session)里面保存相关数据,比如用户角色.登录时间等等. 3.服务器向用户返回一个 session_id,写入用户的 Cookie. 4.用户随后的每一次请求,都会通过 Cookie,将 session_id 传回服务器. 5.服务器收到 session

  • ASP.NET Core学习之使用JWT认证授权详解

    概述 认证授权是很多系统的基本功能 , 在以前PC的时代 , 通常是基于cookies-session这样的方式实现认证授权 , 在那个时候通常系统的用户量都不会很大, 所以这种方式也一直很好运行, 随着现在都软件用户量越来越大, 系统架构也从以前垂直扩展(增加服务器性能) -> 水平扩展(增加服务器数量) cookies-session 工作方式 客户端提交用户信息 -> 服务器识别用户 -> 服务端保存用户信息 -> 返回session-id客户端 -> 客户端保存ses

  • 基于gin的golang web开发之认证利器jwt

    JSON Web Token(JWT)是一种很流行的跨域认证解决方案,JWT基于JSON可以在进行验证的同时附带身份信息,对于前后端分离项目很有帮助. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c JWT由三部分组成,每个部分之间用点

  • 详解SpringCloud服务认证(JWT)

     - JWT JWT(JSON Web Token), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景.JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密. - JWT与其它的区别 通常情况下,把API直接暴露出去是风险很大的,不说别的

  • asp.net基于JWT的web api身份验证及跨域调用实践

    随着多终端的出现,越来越多的站点通过web api restful的形式对外提供服务,很多网站也采用了前后端分离模式进行开发,因而在身份验证的方式上可能与传统的基于cookie的Session Id的做法有所不同,除了面临跨域提交cookie的烦人问题外,更重要的是,有些终端可能根本不支持cookie. Json Web Token(jwt)是一种不错的身份验证及授权方案,简单的说就是调用端调用api时,附带上一个由api端颁发的token,以此来验证调用者的授权信息. 但由于时间关系,不对jw

  • 浅谈node使用jwt生成的token应该存在哪里

    答:通常存储在客户端里. jwt 即 JSON Web Token,是一种认证协议,一般用来校验请求的身份信息和身份权限. 早上逛某乎的时候,遇到一位同学在问这个问题,很好奇jwt的存储位置.刚好前段时间在学习此内容,不请自邀,厚颜强答. 最开始我也很好奇这个token怎么保存,还差点想搞个redis存储这个token. 后来查阅资料才知道,原来这个token,服务端是可以不保存的.只需要客户端保存好就行,无论什么保持方式,甚至你让用户写纸条揣兜里都可以! 那这个token是怎么工作的呢? 先来

  • SpringBoot整合JWT框架,解决Token跨域验证问题

    一.传统Session认证 1.认证过程 1.用户向服务器发送用户名和密码. 2.服务器验证后在当前对话(session)保存相关数据. 3.服务器向返回sessionId,写入客户端 Cookie. 4.客户端每次请求,需要通过 Cookie,将 sessionId 回传服务器. 5.服务器收到 sessionId,验证客户端. 2.存在问题 1.session保存在服务端,客户端访问高并发时,服务端压力大. 2.扩展性差,服务器集群,就需要 session 数据共享. 二.JWT简介 JWT

随机推荐