REST API安全性存储令牌vs JWT vs OAuth

#1 楼

考虑第一种情况。每个客户都会获得一个随机ID，该ID可以持续到会话期间-如果您愿意，可以是几天。然后，将与该会话相关的信息存储在服务器端。它可以在文件或数据库中。假设您通过Cookie传递ID，但可以使用URL或HTTP标头。

会话ID / Cookies

优点：


易于对客户端和服务器进行编码。
易于在有人注销时销毁会话。

缺点：


服务器端定期需要删除客户端未注销的过期会话。
每个HTTP请求都需要查找数据存储。
随着越来越多的用户拥有活动会话，存储需求也随之增加。
如果有多个前端HTTP服务器，所有这些服务器都需要访问存储的会话数据。与将其存储在一台服务器上相比，这可能需要更多的工作。更大的问题是数据存储将成为单点故障，并且可能成为瓶颈。

JSON Web令牌（JWT）

在传递而不是在服务器上传递的JWT中。



服务器端存储问题已消失。
客户端代码很容易。

缺点：


JWT的大小可能大于会话ID。由于它包含在每个HTTP请求中，因此可能会影响网络性能。
JWT中存储的数据可供客户端读取。这可能是一个问题。

服务器端需要代码来生成，验证和读取JWT。这并不难，但是有一些学习曲线，安全性取决于它。

任何获得签名密钥副本的人都可以创建JWT。您可能不知道什么时候发生。

某些库中有一个错误，它接受任何使用“无”算法签名的JWT，因此任何人都可以创建服务器可以信任的JWT。 br />
为了在JWT过期之前撤消JWT，您需要使用撤消列表。这使您回到试图避免的服务器端存储问题。

OAuth

OAuth通常用于身份验证（即身份），但可用于共享其他数据，例如用户已购买并有权下载的内容列表。它还可以用于授予访问权限以写入由第三方存储的数据。您可以使用OAuth对用户进行身份验证，然后使用服务器端存储或JWT来存储会话数据。



无代码供用户注册或重置他们的密码。
没有代码发送带有验证链接的电子邮件，然后验证地址。
用户无需学习/写下其他用户名和密码。

缺点：


您依赖第三方才能使用户使用您的服务。如果他们的服务中断或中止服务，则您需要找出其他解决方案。例如：如果用户的帐户数据从“ foo@a.com”更改为“ bar@b.com”，该如何迁移用户帐户数据？
通常，您必须为每个提供程序编写代码。例如Google，Facebook，Twitter。
您或您的用户可能有隐私问题。提供者知道哪些用户使用您的服务。
您信任提供者。提供者可以将对一个用户有效的令牌发行给其他人。这可能出于合法目的。

其他


两个会话ID和JWT都可以被多个用户复制和使用。您可以将客户端IP地址存储在JWT中并对其进行验证，但这可以防止客户端从Wi-Fi漫游到蜂窝网络。

#2 楼

问问自己自己为什么需要使原始令牌失效。

用户登录，生成令牌，然后关闭应用程序。

用户按下注销，一个新令牌生成并替换原始令牌。再一次，一切都很好。

您似乎担心两个令牌都挂在一起的情况。如果用户注销，然后以某种方式使用登录令牌发出请求，该怎么办？这种情况有多现实？这仅仅是注销过程中的问题，还是在许多可能存在多个令牌问题的情况下？

我自己不认为这值得担心。如果有人正在拦截和解码您的加密https数据，那么您会遇到更大的问题。

您可以通过在原始令牌上放置一个过期时间来为自己提供一些额外的保护。因此，如果最终被盗或被盗，那只能在短时间内有效。

否则，我认为您需要在服务器上具有状态信息。不要将令牌列入黑名单，而是将当前令牌的签名列入白名单。

#3 楼

您可以通过将盐值与用户一起存储并将盐用作用户令牌的一部分来处理您提到的JWT问题。然后，当您需要使令牌失效时，只需更改盐即可。

我知道已经过去了几年了，但实际上我现在会做不同的事情。我想我将确保访问令牌的生存期相对较短，例如一个小时。我还要确保使用服务器上有状态的刷新令牌，然后当我想结束某人的会话时，可以通过将刷新令牌从服务器中删除来撤消刷新令牌。然后，一个小时后，该用户将被注销，必须再次登录才能重新获得访问权限。

#4 楼

宣誓不是认证协议，而是授权标准或协议。因此，例如，如果您使用“添加到Google日历”功能，那就是誓言。该应用程序将列出元素的Google API或指向要传递信息的各个挂钩的URL链接。如果要授权，则要OIDC或openID连接。

对于您的用例，我建议您综合上述所有内容。如果使用OIDC，则用户凭据将通过HTTPS向身份验证服务器进行身份验证。请求中将包含用户的用户名，密码以及应用程序的唯一随机生成的（客户端）ID。如果凭据有效且客户端ID有效，则服务器将使用一次性密码进行响应。然后，用户应用程序将使用该密码并将其传递给Web服务。 Web服务将密码传递回身份验证服务器，以验证密码是否合法。如果是这样，认证服务器将使用授权/访问令牌（AK）响应Web服务。现在，您可以采用以下两种方法之一：

2.1您可以将该令牌作为访问令牌存储在客户端应用程序中。然后让Web服务以刷新令牌进行响应。授权令牌的寿命可能为几个小时或几天，而刷新令牌的寿命将更短。您应该使用JWT作为刷新令牌，但是可以使用较小的随机生成的字符串作为刷新令牌。这样，您不必一定每次请求都传递AK。如果说5分钟过去了，并且服务器没有从用户那里获得刷新令牌，则服务器将断开与用户的连接并使所有令牌失效（AK和刷新）。唯一不利的一面是，如果AK被攻陷，则可能会冒用用户季的风险。

2.2（最推荐）访问令牌和授权通常通常是相同的，但从技术上讲可以是两个不同的令牌。如果用户已经通过身份验证并且您正在通过手机OS硬件API使用他或她的指纹或面部ID，那么这非常好。如果电话说是，这就是他或她，您只需通过无证书的API网关发送客户端ID即可访问密钥存储/存储库。网关将使用您先前生成的身份验证令牌进行响应。然后，应用程序可以将该令牌发送到Web服务，并且Web服务将使用访问令牌和刷新令牌进行响应。然后，您可以丢弃auth令牌，并保留访问和刷新令牌。

这里的想法是，在用户首次进行身份验证并生成auth令牌后，其使用寿命可能为3个月。现在，您不想将其保留在您的客户端电话上，因为如果它受到损害，则用户将被搞砸。因此，为什么要将其保存在不在手机上的密钥库中。现在，Web服务响应的访问令牌的使用寿命为一个小时，刷新令牌的使用寿命为5分钟。只要刷新令牌处于活动状态，会话就会保持活动状态。当您停止接收该刷新令牌时，会使刷新和访问令牌无效，终止会话，您仍然可以保留auth令牌。然后，您的授权应该是带有ES-256算法的JWT。您的访问令牌应该或可以使用RS-256，而刷新令牌可以使用HS-256。 RS＆ES不要使用非对称加密，这意味着您需要使用公共密钥和私有密钥来生成它。 HS使用对称加密，这意味着仅使用一个密码或密钥来生成它。