在我的系统上（Ubuntu Server 18.04，如果重要的话）我有两台服务器。它们位于 Nginx 反向代理之后（即访问service.mywebsite.com内部代理请求127.0.0.1:servicePort）。
我有一台服务器负责对用户进行身份验证并生成访问令牌。基本上，它在客户端浏览器中存储一个“身份验证令牌”cookie，该 cookie 共享给其他服务器（相同的子域）。（我们称之为authenticator）
我的其他服务器应该基于该刷新令牌提供服务。（我们称之为service）
我想象的是让该服务将身份验证器与一个简单的 TCP 套接字连接起来。该服务会将用户的“身份验证令牌”发送给身份验证器，它会响应“是的，这个用户是 myUserName，它有权使用您的服务”）。
问题 1：我（作为服务）连接到 127.0.0.1（身份验证器）这一简单事实是否足以信任它的答案？
问题 2：是否有更简单/更安全的 TCP 方法在身份验证器和服务之间进行通信？（它们将保持在同一个系统上，并且应该是不同的可执行文件）
通过 127.0.0.1 进行通信可以被认为只是另一种 IPC 机制，但它重用了现有协议。就像共享内存或 UNIX 域套接字或管道一样，它是两个进程可以在单个系统上进行通信的无数方式之一。如果您相信系统上的进程没有受到威胁，那么您可以“盲目地”信任通过 127.0.0.1 的连接。
如果您知道 TCP 套接字另一端的 IP 地址是 127.0.0.1，这可以保证系统管理员已将防火墙配置为重定向此特定连接，或者 TCP 套接字的另一端是正在运行的进程同一台机器。因此，如果您整体信任服务器计算机，则可以信任 127.0.0.1。但是，不使用 TCP 套接字有利于纵深防御。
您需要注意如何实施 localhost 检查。本地主机是 127.0.0.1 直到它不是，例如因为您切换到默认使用 IPv6 的某个库的版本，或者因为您决定添加某种形式的转发代理以允许您运行不同机器或容器上的两个服务。如果您开始使用代理，请注意在正确的位置进行检查。当然，你必须确保永远不要在同一台机器上托管任何其他可能不可靠的东西（尽管在那些虚拟机和容器时代你为什么要这样做）。
知道您正在与同一台机器通话只会告诉您同一台机器上的某些进程位于连接的另一端。它并没有告诉你这是正确的过程。在正常操作下，大概两个进程都在运行。但是，如果发生错误，例如一个进程由于拒绝服务攻击而耗尽内存后崩溃，则该端口将可供另一个进程监听。并且在任何时候，任何本地进程都可以连接到正在运行的服务器。这要求攻击者能够在本地运行一些进程，但它可能是一些无特权的进程，否则无法做很多事情。因此，虽然依赖 127.0.0.1 不是漏洞，但它会让您对特权升级持开放态度。
我可以，改用 Unix 套接字。Unix 和 TCP 套接字的工作方式相同，只是指定了要连接或侦听的地址，因此不需要太多代码更改。一个 Unix 套接字可以有权限，或者可以由父主管创建，没有其他东西可以连接到它。使用 Unix 套接字，您可以保证套接字另一端的内容不仅在同一台机器上运行，而且是预期的过程。这只会让您容易受到身份验证器服务或主服务中的安全漏洞的影响，而不是在同一台机器上运行的任何东西的漏洞。