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