我正在构建一个由Angular前端和Node.JS后端组成的Intranet Web应用程序。该应用程序需要使用公司的Active Directory进行身份验证和授权。
我正在考虑如何以安全的方式最好地实现这一目标。我打算使用Active Directory node module与用户进行实际通信，以在用户登录时进行身份验证，并检查安全组成员身份是否存在某些受限操作，等等。
但是，我不太清楚授权后端端点的最佳方法是什么。即使我认为Kerberos用于实际的身份验证过程，AD模块也不提供任何令牌/票证。在我开发的其他经过身份验证的应用程序中，当用户登录时，我生成了一个jsonwebtoken，然后通过并验证了每个后端路由中的令牌，对AD进行身份验证也是一个好主意吗？
编辑：问题的第二部分产生于单独的线程：Best practices for server-side handling of JWT tokens
[此外，对于实际验证令牌的最佳做法，我还有一个更普遍的关注。假设用于JWT生成的“秘密”受到了损害（在我的情况下，许多人可能可以访问系统的源代码，但不能访问系统本身）。我是否认为恶意用户仅凭此信息便可以代表任何给定用户生成令牌，而无需与AD进行身份验证就可以在我的API请求中使用该令牌？通常使用jwt.sign(payload, secretOrPrivateKey, options)生成令牌。或者，假设恶意用户可以持有实际令牌（在令牌过期之前）。对我来说，似乎不必知道用户的用户名和密码，而是将安全性降低到必须知道用户名和JWT机密。这是一个有效的关注点，我应该怎么做才能避免这种情况？
到目前为止，我最大的希望是使用服务器端会话在登录后存储有关当前用户的信息，这样，即使访问后端端点时恶意生成并使用了令牌，除非用户实际经过了令牌，否则令牌将失败。登录路由，经过AD验证，并因此在会话中存储了一些信息。
我还考虑过在[[each API端点中实际使用AD进行身份验证，但这将要求在每个请求中发送AD用户名/密码，这反过来又将必须将敏感信息存储在客户端的会话存储或本地存储，这很可能是个坏主意。
所以，问题：1）将AD授权与JWT作为承载令牌结合在一起是否合理，或者采用AD进行身份验证以构建安全的后端+前端的首选方法是什么？
2）如果JWT是一个好主意，那么使用JWT保护端点的最佳实践是什么？使用服务器端会话是否合理？
有趣的是，我已经找到了很多关于如何最好地实现基于令牌的身份验证的示例（通常，或者特别是使用NodeJS，但是其中许多似乎以一种或另一种方式存在缺陷。
1）将AD授权与JWT作为承载相结合是否合理令牌或构建安全后端的首选方式是什么+前端利用AD进行身份验证？
这是合理的，但是如果您已经在使用Kerberos和AD来对用户进行初始身份验证，则可以考虑使用s4u2proxy
约束委派，它允许服务向KDC展示用户的服务票证并获取（需经过授权检查）后端服务的票证（并重复执行许多必要的服务）。
如果您需要很多
后端服务，则单个JWT承载all服务执行授权策略所需的所有授权声明可能是一个更好的选择。2）如果JWT是个好主意，那么确保安全的最佳实践是什么端点使用JWT？使用服务器端会话是否合理？
适用一般常规安全措施：