ASP NET Core 认证与授权 4 JwtBearer认证

最新推荐文章于 2025-01-18 19:42:35 发布

有点太老了

最新推荐文章于 2025-01-18 19:42:35 发布

阅读量651

点赞数

本文链接：https://blog.youkuaiyun.com/qq_43678418/article/details/86561664

版权

本文介绍了ASP.NET Core中JwtBearer认证的原理与使用，包括Bearer认证的工作流程、JWT的构成（Header、Payload、Signature）以及如何在ASP.NET Core中配置和使用JwtBearer认证。文章通过示例展示了如何模拟Token、注册认证、添加受保护资源，并探讨了扩展和源码解析，最后总结了Bearer认证与JWT的优势。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Bearer认证

HTTP提供了一套标准的身份验证框架：服务器可以用来针对客户端的请求发送质询(challenge)，客户端根据质询提供身份验证凭证。质询与应答的工作流程如下：服务器端向客户端返回401（Unauthorized，未授权）状态码，并在WWW-Authenticate头中添加如何进行验证的信息，其中至少包含有一种质询方式。然后客户端可以在请求中添加Authorization头进行验证，其Value为身份验证的凭证信息。

640?wx_fmt=png&wxfrom=5&wx_lazy=1

在HTTP标准验证方案中，我们比较熟悉的是"Basic"和"Digest"，前者将用户名密码使用BASE64编码后作为验证凭证，后者是Basic的升级版，更加安全，因为Basic是明文传输密码信息，而Digest是加密后传输。在前文介绍的Cookie认证属于Form认证，并不属于HTTP标准验证。

本文要介绍的Bearer验证也属于HTTP协议标准验证，它随着OAuth协议而开始流行，详细定义见： RFC 6570。

A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

Bearer验证中的凭证称为BEARER_TOKEN，或者是access_token，它的颁发和验证完全由我们自己的应用程序来控制，而不依赖于系统和Web服务器，Bearer验证的标准请求方式如下：

Authorization: Bearer [BEARER_TOKEN]

那么使用Bearer验证有什么好处呢？

CORS: cookies + CORS 并不能跨不同的域名。而Bearer验证在任何域名下都可以使用HTTP header头部来传输用户信息。
对移动端友好: 当你在一个原生平台(iOS, Android, WindowsPhone等)时，使用Cookie验证并不是一个好主意，因为你得和Cookie容器打交道，而使用Bearer验证则简单的多。
CSRF: 因为Bearer验证不再依赖于cookies, 也就避免了跨站请求攻击。
标准：在Cookie认证中，用户未登录时，返回一个302到登录页面，这在非浏览器情况下很难处理，而Bearer验证则返回的是标准的401 challenge。

JWT(JSON WEB TOKEN)

上面介绍的Bearer认证，其核心便是BEARER_TOKEN，而最流行的Token编码方式便是：JSON WEB TOKEN。

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（RFC 7519）。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JWT是由.分割的如下三部分组成：

头部(Header)

Header 一般由两个部分组成：

alg是是所使用的hash算法，如：HMAC SHA256或RSA，typ是Token的类型，在这里就是：JWT。

{
       "alg": "HS256",  "typ": "JWT"}

然后使用Base64Url编码成第一部分：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<second part>.<third part>

载荷(Payload)

这一部分是JWT主要的信息存储部分，其中包含了许多种的声明（claims）。

Claims的实体一般包含用户和一些元数据，这些claims分成三种类型：

reserved claims：预定义的一些声明，并不是强制的但是推荐，它们包括 iss (issuer), exp (expiration time), sub (subject),aud(audience) 等（这里都使用三个字母的原因是保证 JWT 的紧凑）。
public claims: 公有声明，这个部分可以随便定义，但是要注意和 IANA JSON Web Token 冲突。
private claims: 私有声明，这个部分是共享被认定信息中自定义部分。

一个简单的Pyload可以是这样子的：

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

这部分同样使用Base64Url编码成第二部分：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>

签名(Signature)

Signature是用来验证发送者的JWT的同时也能确保在期间不被篡改。

在创建该部分时候你应该已经有了编码后的Header和Payload，然后使用保存在服务端的秘钥对其签名，一个完整的JWT如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

因此使用JWT具有如下好处：

通用：因为json的通用性，所以JWT是可以进行跨语言支持的，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
紧凑：JWT的构成非常简单，字节占用很小，可以通过 GET、POST 等放在 HTTP 的 header 中，非常便于传输。
扩展：JWT是自我包涵的，包含了必要的所有信息，不需要在服务端保存会话信息, 非常易于应用的扩展。

关于更多JWT的介绍，网上非常多，这里就不再多做介绍。下面，演示一下 ASP.NET Core 中 JwtBearer 认证的使用方式。

示例

模拟Token

ASP.NET Core 内置的JwtBearer验证，并不包含Token的发放，我们先模拟一个简单的实现：

[HttpPost("authenticate")]
public IActionResult Authenticate([FromBody]UserDto userDto){ 
   var user = _store.FindUser(userDto.UserName, userDto.Password);  
     if (user == null) 
     return Unauthorized(); 
     var tokenHandler = new JwtSecurityTokenHandler(); 
     var key = Encoding.ASCII.GetBytes(Consts.Secret);  
     var authTime = DateTime.UtcNow;  
     var expiresAt = authTime.AddDays(

最低0.47元/天解锁文章