RESTful服务的用户身份验证

Question

我有当前的客户群。我想通过RESTful服务（通过应用程序）让他们访问有关他们自己的某些细节。

我想给客户提供尽可能少的麻烦，因此我正在考虑为每个客户生成一个UUID，然后让他们通过提供他们的UUID作为标识来访问REST。

例如：http://www.example.org/rest/value/UUID或http://www.example.org/rest/value将UUID作为HTTP基本身份验证通过TLS。

我的担心是安全。请记住，我对这些概念中的一些是新手。使用按需生成的UUID作为某个客户的“证明”，我的主要担忧是什么？

如果我的上述情况应该对有人嗅出UUID开放，如果我理论上能够在传输过程中隐藏UUID，也请将其合并。

我知道UUID不是非常容易理解，但输入被认为是通过URL/QR /类似的。

Answer 1

将UUID用作有效用户的固定标识符是有风险的。 UUID生成为be unique, not random。如果攻击者拥有合法的UUID，他可能会尝试猜测其他用户的标识符。

固定的标识符也很容易泄漏。即使您使用HTTPS在传输通道上隐藏标识符，仍然存在用户使用复制链接到电子邮件或某人从屏幕上涂抹标识符的风险。

在HTTP标头中发送标识符会更安全一些，因为HTTP标头不会反映在链接中或显示在屏幕上。但是，如果标识符泄漏，攻击者可以轻松地模拟标识符被盗用的用户。

这就是为什么大多数身份验证系统生成（会话）标识符或令牌在有限的时间内有效。如果它被盗，那么它可以用于有限的窗口。

您没有提及您运行的平台或REST服务是在互联网上还是在Intranet上访问。在后一种情况下，在Windows Active Directory域中，像Integrated Windows Authentication这样的东西可能是最少麻烦的（您使用用户的登录会话）。

否则，你应该看看一些JWT based authentication机制。

Answer 2

考虑实施基于OpenID Connect 1.0规范的认证层。在这种情况下，认证会话的提供者在应用程序的外部。 OpenID规范是可扩展的，所以你可以使用加密，如果你想。

根据需求为每个客户生成的UUID并不能保证安全性。从HTTP会话中嗅出UUID或其他明文信息并不困难。 Open ID Connect的不同之处在于它为应用程序定义了一种方法来建立经过验证的会话并使用唯一的会话标识符来验证每个后续请求。

希望总结有帮助。 有关于它如何在这里工作的更多信息http://openid.net/connect/faq/