如何验证来自其他服务的请求？
我正在设计一个需要用户访问的RESTful Web服务，但也包括其他Web服务和应用程序。 所有传入的请求都需要进行身份验证。 所有通信都通过HTTPS进行。 用户身份验证将基于通过将用户名和密码（通过SSL连接）POST到服务提供的/会话资源而获取的身份验证令牌起作用。
对于Web服务客户端，客户端服务后面没有最终用户 。 这些请求由计划的任务，事件或一些其他计算机操作启动。 预先知道连接服务列表（显然，我猜）。 我应该如何验证来自其他（网络）服务的这些请求？ 我希望身份验证过程尽可能简单地实现这些服务，但不以安全为代价。 像这样的场景的标准和最佳实践是什么？
我能想到的选项（或者已经向我建议）：
让客户端服务使用“假”用户名和密码，并以与用户相同的方式对其进行身份验证。 我不喜欢这个选项 - 它只是感觉不对。
为客户服务分配一个永久的应用程序ID，也可能是应用程序密钥。 据我了解，这与使用用户名+密码相同。 使用此ID和密钥，我可以对每个请求进行身份验证，也可以创建一个身份验证令牌来验证其他请求。 无论哪种方式，我不喜欢这个选项，因为任何能够获得应用程序ID和密钥的人都可以模拟客户端。
我可以添加一个IP地址检查到以前的选项。 这会使得执行虚假请求变得更困难。
客户证书。 设置我自己的证书颁发机构，创建根证书并为客户机服务创建客户机证书。 但是，我想到了几个问题：a）我如何仍然允许用户在没有证书的情况下进行身份验证; b）从客户端服务的角度来看，这种情况有多复杂？
还有其他的东西 - 那里必须有其他解决方案吗？
我的服务将运行在Java上，但我故意忽略了它将构建的具体框架的信息，因为我对基本原则更感兴趣，而不是关注实现细节 - 我认为这是最好的解决方案无论底层框架如何，都可以实现。 但是，我对这个主题有点缺乏经验，所以对于实际实现（如有用的第三方库，文章等）的具体提示和示例也将非常感激。
任何解决这个问题的办法都归结为共同的秘密。 我也不喜欢硬编码的用户名和密码选项，但它确实有很简单的好处。 客户证书也很好，但它真的有很大的不同吗？ 服务器上有一个证书，客户机上有一个证书。 它的主要优点是难以暴力。 希望你有其他的保护措施，以防止这种情况发生。
我认为客户端证书解决方案的A点难以解决。 你只是使用一个分支。 if (client side certificat) { check it } else { http basic auth }我不是Java专家，我从来没有使用它来做客户端证书。 然而，快速谷歌引导我们看这个教程，看起来就在你的胡同。
尽管所有这些都是“最好的”讨论，但我还是要指出，还有另外一种哲学说：“少编码，少聪明就好”。 （我个人认为这个理念）。 客户端证书解决方案听起来像很多代码。
我知道您表达了有关OAuth的问题，但OAuth2提案确实为您的问题提供了解决方案，称为“持票人令牌”，必须与SSL一起使用。 我认为，为了简单起见，我会选择硬编码的用户/密码（每个应用程序一个，以便可以单独撤销）或非常相似的持证人代币。
看完你的问题后，我会说，生成特殊的令牌来做请求。 这个令牌将在特定的时间生活（可以说在一天内）。
以下是生成身份验证令牌的示例：
(day * 10) + (month * 100) + (year (last 2 digits) * 1000)
例如：2011年6月3日
(3 * 10) + (6 * 100) + (11 * 1000) =
30 + 600 + 11000 = 11630
然后连接用户密码，例如“my4wesomeP4ssword！”
11630my4wesomeP4ssword!
然后做该字符串的MD5：
05a9d022d621b64096160683f3afe804
你什么时候调用请求，总是使用这个令牌，
https://mywebservice.com/?token=05a9d022d621b64096160683f3afe804&op=getdata
这个令牌每天都是独一无二的，所以我想这种保护足以保护我们的服务。
希望有帮助
:)
您可以采取几种不同的方法。
RESTful纯粹主义者会希望您使用BASIC身份验证，并在每个请求上发送凭据。 他们的理由是没有人存储任何状态。
客户端服务可以存储cookie，该cookie保存会话ID。 我个人认为这不像我听到的一些纯粹主义者那样冒犯 - 一遍又一遍地认证可能是昂贵的。 这听起来像你不太喜欢这个想法。
从你的描述来看，这听起来好像你可能对OAuth2感兴趣。迄今为止，从我看到的情况来看，我的经验是它有点令人困惑，而且有点出血。 那里有一些实现，但它们很少。 在Java中，我明白它已被集成到Spring3的安全模块中。 （他们的教程写得很好。）我一直在等待看看Restlet中是否会有扩展，但到目前为止，尽管已经提出，并且可能在孵化器中，但它尚未完全合并。