jwt获取token_JWT和HMAC(AK/SK)认证方式使用场景

本文主要讨论一下jwt和HMAC(AK/SK)的使用场景

jwt

一般是由用户先发送用户名、秘密，认证通过后服务器返回jwt，其中包含三段信息：

Header，记录jwt元数据
Payload，记录真实要传递的数据
Signature，记录数据签名

其中Signature是根据jwt签名算法+服务端自定义的秘钥生成的hash信息

关键就是这个服务器自定义秘钥，达到两个效果：

1. 完整性验证，如果传输过程中被篡改，签名会对不上（这个由hash算法保证）
2. 验证成功，同时也意味着认证成功

由于自定义秘钥，也限制了jwt一般用于单一服务的登陆和认证，对于多个服务，可能由于各自的秘钥不一致，甚至Payload信息不一样，无法在多个服务之间跨服务认证

适用场景：

1. 存在用户登陆，用户通过密码换取jwt，后续使用jwt交互
2. 简单的实体认证，由服务方直接分发一个生成的jwt给另一方，另一方每次带着jwt访问接口，常用于认证其他接口实体，但安全性较弱

HMAC(AK/SK)

HMAC预先生成一个 access key（AK） 和 secure key（SK），然后通过签名的方式完成认证请求，这种方式可以避免传输 secure key，且大多数情况下签名只允许使用一次，避免了重放攻击。

基本过程如下：

1. 客户端需要在认证服务器中预先设置 access key（AK 或叫 app ID） 和 secure key（SK）
2. 在调用 API 时，客户端需要对参数和 access key 进行自然排序后并使用 secure key 进行签名生成一个额外的参数 digest
3. 服务器根据预先设置的 secure key 进行同样的摘要计算，并要求结果完全一致

func 

与jwt的区别：

服务端不仅有一个秘钥，同时还给每个调用实体分发一个appid

数据由调用双方约定好，可以是map、array、string等任意数据

带有时间戳验证，每次调用的签名都不一样，安全性高

签名是双方根据算法自动计算，不需要登陆换取token

适用场景：

api间互相调用的认证

jwt和hmac结合实现跨系统调用

在平时开发中一种常见的场景是一个用户从服务A跳转到服务B，而且是带着服务A的认证（token或者cookie）过来，如果让用户从新登陆也不合适，常见的做法是：

1. 服务B获取服务A的token
2. 服务B使用服务A预先分发的ak和sk，将token作为数据，使用HMAC算法计算签名
3. 服务B调用服务A的token认证解析接口
4. 服务A返回是否认证以及认证的结果
5. 服务B根据认证结果进行下一步操作

补充

认证是 authentication，指的是当前用户的身份，当用户登陆过后系统便能追踪到他的身份做出符合相应业务逻辑的操作。即使用户没有登录，大多数系统也会追踪他的身份，只是当做来宾或者匿名用户来处理。认证技术解决的是 “我是谁？”的问题。

授权则不同，授权是 authorization，指的是什么样的身份被允许访问某些资源，在获取到用户身份后继续检查用户的权限。单一的系统授权往往是伴随认证来完成的，但是在开放 API 的多系统结构下，授权可以由不同的系统来完成，例如 OAuth。授权技术是解决“我能做什么？”的问题。

细说API - 认证、授权和凭证​insights.thoughtworks.cn

cookie、session、jwt不是本文重点，具体见

李志华：cookie、session、jwt​zhuanlan.zhihu.com