2

我正在实施一个休息 api 来使用新的 web api 框架。此 api 将被其他公司使用，因此我们将添加一种身份验证方法。

关于身份验证，我正在考虑基于令牌实现一些东西。像这样的东西

  • 客户端提供登录方法的凭据
  • 系统验证客户端并发送令牌
  • 客户端在以下 api 调用中使用此令牌

我想知道这个模式是否对我的场景有用。操作将主要是原子的，基本上客户端会定期 ping 这个 api 以获取一些特定的数据，所以不确定拥有会话令牌是否有意义（在某些时候令牌应该过期并且不确定如何管理它）。

您如何建议为这种情况实施身份验证架构？

4

2 回答 2

2

当您生成一个令牌时，我会将它存储在一个数据库中，并使用一个外键返回到经过身份验证的登录的​​主键。我还将（使用令牌）存储它建立的日期和时间，以及超时期限（您可以为每个令牌设置它，或将其存储在配置中）。每次该用户 ping 服务时检查令牌/时间，然后在该时间到期后强制他们重新进行身份验证（通过检查与令牌一起存储的创建日期）。

这将确保仅在令牌过期后才传输登录信息，当生成新令牌时，它将删除旧令牌记录。

我理解你的要求对吗？

于 2012-08-09T13:50:52.747 回答
1

制作这样一个基于令牌的身份验证方案并不容易。

对于如何以良好和安全的方式实施它，我真的没有答案。但是会在我脑海中提供一些关于您必须处理的问题的想法：

  • 令牌生成需要很好地随机化，并且令牌需要“足够”（对于足够的定义）长，以防止某人简单地发送一堆不同的令牌来查看他是否“受到打击”

上述问题实施起来应该不会太难。但更棘手的是要弄清楚：

  • 如何可靠地验证令牌没有被“绑架”。

如果令牌只是一些随机字符串，那么任何碰巧在传输（使用 SSL）中“看到”它的人都将能够假定生成令牌的用途的身份。

当您的服务收到令牌时，您会知道：

  • 您的应用程序将令牌颁发给用户/应用程序/实体 X
  • 令牌完好无损（未更改）
  • 您使用令牌存储的任何其他内容（是否已过期等）

但它不会没有进一步的努力让您确定它是由用户/应用程序/实体 X 发送的。可能是 Y 已经设法获得了令牌。

当然，许多身份验证方案都是这种情况，因此取决于您的数据的敏感程度，以及可以通过您的服务执行什么样的操作，这对您来说可能不是一个大问题。

于 2012-08-09T15:16:25.387 回答