我正在设计将由第三方使用的宁静网络服务。他们需要通过身份验证才能使用我的Restful服务。为此，我计划使用两种方法对其进行身份验证。
使用其他Restful服务作为代理来访问Restful服务： 要访问RESTful服务，用户将在POST方法中将用户名和密码发送到此代理类。当用户名和密码正确时，将生成唯一ID（例如，身份验证密钥）并在响应中发送。当下一个请求发出后，用户将在请求有效负载中发送认证密钥（以及访问目标Restful服务的其他详细信息）。此认证密钥将由代理验证。如果密钥有效，代理将调用目标restful服务并将响应返回给客户。否则将在共鸣中发送错误消息。
基于Servlet的身份验证： 与第一种方法相同，但servlet将作为访问webservices的代理。在这种方法中，用户名和密码将由servlet验证，如果正确，servlet将在响应中设置一些cookie并将其发送到客户端.Next用户发送请求cookie的时间将被验证。如果它有效，则servlet将调用Restful服务并发送响应。但是我不确定用户请求是否包含cookie。
在第一种方法中，用户需要为每个请求发送身份验证密钥。 但在第二种方法中则不需要。
我需要知道哪种方法更好？还有其他任何方法来处理这个......
答案 0 :(得分：0)
说实话，我不是servlet或Java的专家，我知道如何用Java做很多事情，但这不是我的主要环境。但是，我确实非常了解安全性，特别是REST。
您的第一种方法是经典方法，它不需要代理。它确实很好用，但你可以简化它没有代理服务。
不推荐第二个。有几篇文章指出了基于cookie的解决方案中的许多问题。事实上，他们更容易冒充并获取非法访问权限。你永远不会发送一个cookie，你发送的确是一个包含cookie的一些信息的标题。请记住，您始终以这些机制以某种方式发送授权信息。无论你如何做，以及对客户是否透明，授权必须旅行，因为REST的主要原则是状态：
对Api的每一个请求都是完全隔离的。 ...将服务器哄骗到达页面的状态是不正确的
向我的团队引用自己的话。
在使用一种非常着名的方法方面，我会选择广泛使用的OAuth 2.0。这个概念类似于您在安全协商时发出承载令牌的方法：
http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html
令牌本身包含大量信息，根据您可能公开的敏感信息，有几篇关于它们的文章。
一种更好的机制是使用公钥Cripthography，服务器可以发出您可以使用公钥验证的签名消息，但这种方法超出了我们可以在一个小答案中解决的范围。
它总是取决于您的服务的敏感程度，在您需要的安全性以及可以花费的资源和时间方面总是需要权衡。