我有一个现有的客户群。我希望通过RESTful服务（通过应用程序）让他们访问自己的某些细节。
我希望尽快为客户提供这方面的麻烦，因此我考虑为每个客户生成UUID，然后让他们通过提供UUID作为标识来访问REST。 / p>
例如：http://www.example.org/rest/value/UUID或http://www.example.org/rest/value，其中UUID为TLS上的HTTP基本身份验证。
我担心的是安全。请记住，我是其中一些概念的新手。使用UUID按需生成的主要问题是＆＃34;证明＆＃34;成为某个客户？
如果我的上述场景应该向嗅探UUID的人开放，请理解我是否能够在运输过程中隐藏UUID。
我知道UUID不是人类可读，但输入被认为是通过URL / QR /类似。
答案 0 :(得分：1)
将UUID用作有效用户的固定标识符存在风险。 UUID生成为be unique, not random。如果攻击者拥有合法的UUID，他可能会尝试猜测其他用户的标识符。
固定标识符也很容易泄露。即使您使用HTTPS来隐藏传输通道上的标识符，仍然存在用户使用链接复制到电子邮件或某人从屏幕上删除标识符的风险。
在HTTP标头中发送标识符更加安全，因为HTTP标头不会反映在链接中或显示在屏幕上。但是，如果标识符泄露，攻击者很容易冒充标识符被盗的用户。
这就是为什么大多数身份验证系统生成（会话）标识符或令牌，这些标识符或令牌在有限时间内有效。如果它被盗，可以使用它的窗口有限。
您没有提到您正在运行的平台，或者是否在Internet或Intranet上访问REST服务。在后一种情况下，在Windows Active Directory域中，Integrated Windows Authentication之类的东西可能是最不麻烦的（您使用用户的登录会话）。
否则你应该看一些JWT based authentication机制。
答案 1 :(得分：0)
考虑实施基于OpenID Connect 1.0规范的身份验证层。在这种情况下，经过身份验证的会话提供程序在应用程序外部。 OpenID规范是可扩展的，因此您可以根据需要使用加密。
根据需要为每个客户生成UUID并不能保证安全性。从HTTP对话中嗅出UUID或其他明文信息并不困难。 Open ID Connect的不同之处在于它为应用程序定义了一种建立经过身份验证的会话的方法，并使用唯一的会话标识符来验证每个后续请求。
希望总结有所帮助。 有关它如何运作的更多信息http://openid.net/connect/faq/