【发布时间】:2017-05-19 23:08:52
【问题描述】:
我正在研究 RESTfull API 管理,我发现有些难以理解 API KEY 概念究竟是如何处理安全性的。
所以根据我对一些教程的理解,我有以下情况:
想要使用我的 API 的用户必须注册,注册后,他会获得他的个人 API KEY(类似于一个长随机字符串)。
所以这个秘密和它的秘密一起存储在数据库中,所以在用户注册后,我会在数据库表中保存类似的内容(如果我做错了断言,请纠正我,因为我完全不确定):
+--------------------------------------------------------+
| USER API_KEY API_SECRET |
+--------------------------------------------------------+
| user1 dfdsf3dsfsdg35gsgg4fdgd SECRET1 |
| user2 vbgggh3bfdgdf2gfdgd5vbb SECRET2 |
| user3 gfgdfgd57bfgdfg9dgfd2vg SECRET3 |
+--------------------------------------------------------+
- USER 列包含注册用户。
- API_KEY 包含获取的 api 密钥,必须插入到此用户开发的应用程序中。
- API_SECRET究竟是什么?据我了解,是生成API KEY时自动生成的,还是用户在注册过程中指定的密码?这一点对我来说很模糊。究竟是什么?
现在让我们考虑客户端如何在 API 服务器上执行自动化。
它发送一个 JWT (JSON WEB TOKEN),可能类似于:XXXXX.YYYYY.ZZZZZ
它分为3个不同的部分:
1) YYYY:标题。 BASE64 编码。 CONTIEN 元数据。
类似:
{
type : "JWT",
alg : "HMAC"
}
它将以 base64 编码,因此生成 XXXXX 部分。
2) YYYY:PAYLOAD:包含声明,如下所示:
{
exp : 2828288, // REGISTERED
iss: "myApiProvided.com", // REGISTERED
name: "Andrea" // PUBLIC
}
它将以 base64 编码,因此生成 YYYYY 部分。
3) ZZZZZ: SIGNATURE 创建方式如下:
通过以下连接创建一个字符串:前一个:XXXXX + "." + YYYYY(都是base64编码)。
然后使用 SECRET 生成先前签名的散列。因此,从我基本上以这种方式了解的情况来看,我有一个加密版本的签名。对吗?
在这里,我有第二个疑问:据我了解,此散列必须由发送附加到请求的令牌的客户端生成。那么这个散列是在客户端进行的吗?如果是,则表示客户知道SECRET,但我觉得很奇怪。
具体是如何工作的?
【问题讨论】:
标签: web-services rest security jwt restful-authentication