我目前正在研究在 java 中与 REST API 配合良好的身份验证协议。有一些基本的东西我不明白：我阅读了很多关于 OAuth 协议、SSL、基本 HTTP 身份验证、摘要等的材料。在所有这些材料中，“客户端”一词显然具有不同的含义。在大多数情况下，据我了解，这个术语指的是 Web 应用程序或浏览器。但在某些情况下，例如基本 HTTP 身份验证，该术语指的是用户本人。
我不明白如何才能对 Web 应用程序的实例进行身份验证，或者需要对其进行身份验证。我知道这个过程中涉及到证书，但正如我所看到的，它们只是负责将消息安全地传输到服务器，并防止重放和 MITM 攻击。在OAuth中，在用户名+密码交换之后，证书中需要一个令牌，但是由于用户名和密码属于用户自己，据我所知，验证客户端的部分在哪里？
有一些协议在服务器端和客户端都使用私钥和公钥，这实际上确保了客户端是“它所说的那个人”。但是这些密钥是否必须应用于此 Web 应用程序的每个实例？我糊涂了。
无论如何，在哪些情况下，我们需要客户端身份验证？对用户进行身份验证并注意消息完整性还不够吗？
客户端是一个网络概念：数据在服务器和客户端两台机器之间传输。客户是发起对话的人；服务器是整天坐着等待客户端连接的服务器。
用户是控制客户端的生物实体（假定为人类）。身份验证是关于服务器确保它接收到的任何内容都来自特定用户。但是，服务器不是与用户（人）交谈，而是与客户端（用户的计算机）交谈。当服务器通过存储的HTTP cookie对用户进行身份验证时，它实际上是在对客户端进行身份验证：由于 cookie 值先前已发送到特定客户端，因此只有该客户端可以显示确切的 cookie 值。然后，服务器假定给定客户端处于其声称的人类所有者的排他控制之下，然后感觉到人类用户参与其中的内容。
当用户的机器被破坏（例如被恶意软件感染）时，客户端和用户之间的区别变得明显。机器将开始做人类用户无法控制的事情。
打个比方，如果你有一条狗，那条狗咬我，那我会起诉你，而不是狗，因为狗应该在你的控制之下。即使狗感染狂犬病（解释其报复行为），这仍然是您的责任。从这个意义上说，对狗进行身份验证与对您进行身份验证一样好（至少在我的律师眼中），并且由您来确保您的狗确实在您的独家控制之下。
使用 Web 应用程序和“API”，情况可能会变得更加复杂，因为服务器也可以作为与另一台服务器相关的客户端。该辅助服务器可能希望确保第一台服务器或启动整个过程的人类用户的身份，或两者兼而有之。如果重复使用相同的术语，则术语可能会造成混淆。
当使用公钥/私钥对时，私钥所有者（包含私钥的机器）使用它来执行一些计算，该计算链接到另一个涉及公钥的计算。例如，使用数字签名，私钥所有者在给定消息（字节序列）上生成签名；签名可以验证通过使用公钥。数字签名是一种很好的身份验证工具：通过计算验证者发送的挑战的签名，私钥所有者向该验证者证明其对私钥的掌握。验证者因此获得了一个保证，即它确实在与“控制与给定公钥对应的私钥的人”交谈。该过程的有趣部分是验证者不需要知道私钥，因此可以在没有生成签名的权力的情况下验证签名。
在 OAuth 中，有三方，资源所有者（用户），客户端（被验证的应用程序和资源服务器（实际验证用户凭据的服务器）。客户端是 Web 应用程序，因为它想要的资源服务器来验证（并可能提供有关）尝试登录的资源所有者（用户）的详细信息。
对几种 OAuth 模式的客户端进行身份验证很重要，因为有关用户的详细信息，甚至可能是在资源服务器上使用用户帐户的权限，都将被授予 Web 应用程序（客户端）。
术语的使用令人困惑，因为客户端通常是用户的同义词，但在 OAuth 的情况下，这正是他们选择术语的方式。
在其他系统中，客户端和用户之间的区别可能意味着连接的计算机是否经过验证或使用它的人。一些身份验证机制旨在验证硬件而不是用户。例如，一个计算机系统可能有一个由多个用户共享的私有证书，该证书验证正在使用的客户端是给定的计算机，但它不会提供有关该计算机用户的详细信息。