我无法找到其他人来应对的奇怪情况。我们正在使用Microsoft AspNetCore.Identity处理我们的身份验证。一切正常。问题是，对于一个用户执行某些动作，他们必须让另一个用户“签名”该动作。当然，此签名操作要求其他用户使用其用户名和密码来签名该操作。问题在于，其他用户的详细信息在请求有效负载中很容易看到。因此，如果我偷偷摸摸，可以在浏览器中打开开发人员工具（并将其隐藏），然后请管理员来签署我的操作，当他们离开后，我可以转到“网络”标签，查看其用户名和登录信息用纯文本！当然，这整个都是通过https进行的，但是仍然不能允许一个用户看到另一个用户的敏感信息。我们如何管理以允许第二个用户B在用户A的活动会话中为用户A“签署”一项操作，同时删除用户A窃取用户B的凭据的能力？有任何想法吗？ （前端是angular.js）
我想这是一个很大的返工，但是代替让“ admin”在用户计算机上签署请求，管理员可能会收到“用户A需要对此操作进行签名，继续吗？[确定] [取消]”他们的帐户，该操作将存储在数据库中（也许是临时存储吗？），然后所有敏感信息都将保存在每个用户的会话中，并且不会发生交叉。
然后，可以通过标准身份方法在后端处理允许谁批准操作的身份验证。
用户的“管理员请稍等，请稍候”模式（假设）然后可以轮询API以确定操作的状态，一旦被接受，就可以继续。
如果您需要授权并通过身份验证的用户来签名/确认操作，则我第二个@justcompile的回答，这是更多的工作，但这是唯一的安全方法。
[如果您只需要第二只眼睛来确认，您可以通过一个包含令牌的一次性URL向私人消息组或闲置频道发送消息，只有经过“授权”的人才能访问该令牌（该令牌也可能在一段时间后过期）。
假设管理员仅访问该频道，他们可以访问该链接，该应用可以验证令牌并确认操作。
省去了第二位（管理员）用户在自己的计算机上登录以及建立工作流和UI等的需要，但是如果恶意类型可以访问通道或发送给它的链接，这又使您面临风险。
我猜这取决于您对风险的胃口。
另一个用户在您的本地系统上执行签名操作？你很狡猾？无法保护他们的密码。
使用两因素验证。
通常处理此问题的方式是用户请求操作。该（未签名的）操作请求记录在数据库中。管理员用户可以在其帐户中看到此未签名的请求，并发出一个（经过身份验证的）请求以对其进行签名。用户将能够查看其请求的状态以及该请求是否已签名。