我正在构建一个由 Angular 前端和 Node.JS 后端组成的 Intranet Web 应用程序。应用程序需要使用企业Active Directory 进行身份验证和授权。
我正在考虑如何以安全的方式最好地实现这一点。我打算使用Active Directory 节点模块 https://www.npmjs.com/package/activedirectory用于与 AD 实际通信以在用户登录时进行身份验证，并检查安全组成员资格以执行某些受限操作等。
但是，我不太确定授权后端端点的最佳方式是什么。 AD 模块不提供任何令牌/票证，尽管我认为 Kerberos 用于实际的身份验证过程。在我开发的其他经过身份验证的应用程序中，我在用户登录时生成了一个 jsonwebtoken，然后在每个后端路由中传递并验证了该令牌，这在针对 AD 进行身份验证时也是一个好主意吗？
编辑：问题的第二部分产生到单独的线程：服务器端处理 JWT 令牌的最佳实践 https://stackoverflow.com/questions/30523238/best-practices-for-server-side-handling-of-jwt-tokens
另外，我还有一个更普遍的担忧，即实际验证令牌的最佳实践是什么。假设用于 JWT 生成的“秘密”被泄露（在我的场景中，许多人可能有权访问系统的源代码，但不能访问系统本身）。我是否正确地相信，恶意用户仅使用此信息就可以代表任何给定用户生成令牌，并且无需使用 AD 进行身份验证，就可以在我的 API 请求中使用该令牌？令牌通常使用以下方式生成jwt.sign(payload, secretOrPrivateKey, options)。
或者，假设恶意用户可以获取实际令牌（在其过期之前）。对我来说，安全性现在似乎不再需要知道用户的用户名和密码，而是必须知道用户名和 JWT 秘密。这是一个合理的担忧吗？我应该采取什么措施来防止这种情况发生？
到目前为止，我最大的希望是在登录后使用服务器端会话来存储有关当前用户的信息，这样即使在访问后端端点时恶意生成并使用令牌，除非用户实际完成了登录，否则它也会失败路由，通过 AD 进行身份验证，并因此在会话中存储一些信息。
我还考虑过使用 AD 进行实际身份验证eachAPI 端点，但这需要在每个请求中发送 AD 用户名/密码，这反过来又要求必须将敏感信息存储在客户端的会话存储或本地存储中，这很可能是一个坏主意。
那么，问题：
1）将 AD 授权与 JWT 作为不记名令牌结合起来是否合理，或者使用 AD 进行身份验证构建安全后端 + 前端的首选方式是什么？
2) 如果 JWT 是个好主意，那么使用 JWT 保护端点的最佳实践是什么？使用服务器端会话合理吗？
有趣的是，我发现了大量关于如何最好地实现基于令牌的身份验证（一般情况下，或具体使用 NodeJS）的示例，但其中许多示例似乎都存在这样或那样的缺陷。
