asp.net core 基于jwt的认证(一)

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

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为cookie,以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了。

几种常见的传统认证机制

http basic auth

http basic auth简单点说明就是每次请求api时都提供用户的username和password，简言之，basic auth是配合restful api 使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的restful api时，尽量避免采用http basic auth。

oauth

oauth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

oauth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，oauth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容
下面是oauth2.0的流程：

cookie auth

cookie认证机制就是为一次请求认证在服务端创建一个session对象，同时在客户端的浏览器端创建了一个cookie对象；通过客户端带上来cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效；

token 简介

jwt (json web token)是为了在网络应用环境间传递声明而执行的一种基于json的开放标准。

jwt的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。

有些朋友可能会认为，我登录只需要用缓存或者数据库记录下一个特征码或者是cookies就可以了，为什么要使用jwt呢？我们知道一个数据库或者是一个软件，损耗时间最大的地方就是我们的 i/o(输入输出，通常指的就是硬盘的读写)，因此我们选择解码一次hs256，对于现在的计算能力强大的计算机而言，解一次hs256比访问一次磁盘要快得多。

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
流程上是这样的：

• 用户使用用户名密码来请求服务器
• 服务器进行验证用户的信息
• 服务器通过验证发送给用户一个token
• 客户端存储token，并在每次请求时附送上这个token值
• 服务端验证token值，并返回数据

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持cors(跨来源资源共享)策略，一般我们在服务端这么做就可以了access-control-allow-origin: *。
那么我们现在回到jwt的主题上。

jwt 的组成

我们先来看一段jwt

eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjzdwiioiixmjm0nty3odkwiiwibmftzsi6ikpvag4grg9liiwiywrtaw4ionrydwv9.tjva95orm7e2cbab30rmhrhdcefxjoyzgefonfh7hgq

仔细观察我们可以发现这一段字符串中含有两个 " . ",这两个 " . "把jwt分成了三份，我们分别成为头部、荷载信息、签证信息。那么这三部分的分工是什么呢？

header

jwt的头部承载了两个信息

• 声明类型,对于jwt来说就是jwt
• 加密算法，通常使用sha256,hs256

完整的头部应该是像这样的一个json

{
  'typ': 'jwt',
  'alg': 'hs256'
}

将头部json进行base64加密就得到了我们的第一部分

eyj0exaioijkv1qilcjhbgcioijiuzi1nij9

payload

第二部分是荷载信息，payload,你可以理解为我们的jwt是一辆大仓库，第一部分头部就是仓库的名称编号等基础信息，而荷载信息就是仓库的本身，包含了仓库里面的所有货物。这些信息又包含了三个部分：

• 标准中注册的声明
• 公共的声明
• 私有的声明

标准中注册的声明 (建议但不强制使用) ：

• iss: jwt签发者

• sub: jwt所面向的用户

• aud: 接收jwt的一方

• exp: jwt的过期时间，这个过期时间必须要大于签发时间

• nbf: 定义在什么时间之前，该jwt都是不可用的.

• iat: jwt的签发时间

• jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

公共的声明 ：

公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要息。但不建议添加敏感信息，因为该部分在客户端可解密。

私有的声明 ：

私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

事实上我们的header和payload都是基于base64加密的，这种密文都是可以对称解密的，因此请不要存放敏感信息。

定义一个payload:

{
  "sub": "1234567890",
  "name": "john doe",
  "admin": true
}

进行base64加密后，得到了我们的第二部分

eyjzdwiioiixmjm0nty3odkwiiwibmftzsi6ikpvag4grg9liiwiywrtaw4ionrydwv9

signature

jwt的第三部分是一个签证信息，这个签证信息由三部分组成：

• header (base64后的)
• payload (base64后的)
• secret

这一部分可以理解为对前部分的一个校验，将前两部分加密后的密文通过在header中定义的加密方式，与服务端所传入的密钥进行一次加密，假如前两部分的信息被篡改的话，必然通不过最后一部分签证的校验。因此通过这样保证了jwt的安全性。

因此，保存并隐藏好我们的加密密钥是非常重要的，假设泄露了，就意味着任何知道密钥的人都可以轻松的对jwt进行自我签发和验证。