Web api身份验证架构

Question

我正在使用新的web api框架实现rest api。这个api将由其他公司使用，因此我们将添加一种身份验证方法。

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

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

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

您如何建议为此方案实施身份验证架构？

Answer 1

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

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

我理解你的要求吗？

Answer 2

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

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

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

上述问题不应太难实施。但要弄清楚的更棘手的事情是：

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

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

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

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

但是如果没有进一步的努力，你肯定会知道它是由用户/应用程序/实体X发送的。可能是Y，谁设法获得了令牌。

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