在IEEE 802.1X术语中，这将是请求者：

   Authenticator
          Authenticator 是一个需要从
         请求者。  Authenticator 可以连接到
         点对点 LAN 网段另一端的请求者或
         802.11 无线连接。

   请求者
         Supplicant 是一个正在被认证的实体
         身份验证器。  请求者可以连接到
         位于点对点 LAN 网段一端的身份验证器或
         802.11 无线连接。

（来源）

在其他上下文中，被验证的实体通常被简单地称为客户端或用户，因为在大多数情况下这是明确的。

虽然 Arminius 涵盖了 802.1X 的领域，但我想从授权标准/框架的角度添加我的答案。

OAuth 2.0

RFC 6749 的第 1.1 节定义了几个关键术语：

  资源所有者
      能够授予对受保护资源的访问权限的实体。
      当资源所有者是一个人时，它被称为最终用户。

  资源服务器
      托管受保护资源的服务器，能够接受
      并使用访问令牌响应受保护的资源请求。

  客户
      代表受保护资源请求的应用程序
      资源所有者及其授权。“客户”一词确实
      不暗示任何特定的实现特征（例如，
      应用程序是否在服务器、桌面或其他设备上执行）。

在这里，规范区分了客户端（请求身份验证的应用程序）和最终用户，或者更一般地说，资源所有者。

SAML 2.0

SAML 2.0 词汇表中定义了相关术语：

最终用户将资源用于应用目的的自然人（与系统管理目的相反；请参阅管理员、用户）。

主体可以验证其身份的系统实体。

请求者，SAML 请求者一个系统实体，它利用 SAML 协议从另一个系统实体（SAML 授权、响应者）请求服务。这个概念没有使用术语“客户端”，因为许多系统实体同时或连续充当客户端和服务器。在使用 SAML 的 SOAP 绑定的情况下，SAML 请求者在架构上不同于初始 SOAP 发送者。

用户出于任何目的使用系统及其资源的自然人

可以根据上下文使用各种词。这是我遇到的一些-

1. 人类用户登录机器或服务（CLI 或基于 Web）=用户或最终用户
2. 需要验证的机器用户帐户 - Client（在客户端服务器模型中）或Peer（在对等模型中）
3. 正如 Arminius 所说，这可以进一步抽象为Requester或Customer，具体取决于使用它的位置。

从您的问题来看，这似乎是针对代码的。在这种情况下，我建议保持简单 - 根据上述上下文之一选择一个名称并评论您的代码以明确变量代表的内容:-)

让它容易被主流听到：

描述一个人（人类）时的“用户”（普通）一般

或者

“系统用户”在描述具有较少交互能力（例如无法访问登录对话框）的系统、进程或程序时。