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