在 NodeJS 后端使用 JWT 和 Active Directory 身份验证 [英] Using JWT with Active Directory authentication in NodeJS backend

查看:22
本文介绍了在 NodeJS 后端使用 JWT 和 Active Directory 身份验证的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在构建一个由 Angular 前端和 Node.JS 后端组成的 Intranet Web 应用程序.应用程序需要使用企业 Active Directory 进行身份验证和授权.

I am building an intranet web application consisting of an Angular frontend and a Node.JS backend. The application needs to use the corporate Active Directory for authentication and authorization.

我正在考虑如何以安全的方式最好地实现这一点.我打算使用 Active Directory 节点模块 与 AD 进行实际通信以在用户进行身份验证时使用登录,并检查安全组成员的某些受限操作等.

I'm considering how to best implement this in a secure way. I am planning to use the Active Directory node module for actually communicating with the AD to authenticate when the user logs in, and to check security group membership for certain restricted actions, etc.

但是,我不太确定授权后端端点的最佳方式是什么.AD 模块不提供任何令牌/票证,即使我认为 Kerberos 用于实际的身份验证过程.在我开发的其他经过身份验证的应用程序中,我在用户登录时生成了一个 jsonwebtoken,然后在每个后端路由中传递并验证了该令牌,在针对 AD 进行身份验证时这也是一个好主意吗?

However, I am not quite sure what is the best way to authorize my backend endpoints. The AD module does not offer any token/ticket, even though I suppose Kerberos is used for the actual authentication process. In other authenticated apps I've developed I've generated a jsonwebtoken when the user logs in, and then passed and verified that token in each backend route, is that a good idea also when authenticating against AD?

问题的第二部分产生于单独的线程:服务器端处理 JWT 令牌的最佳实践

Second part of question spawned to separate thread: Best practices for server-side handling of JWT tokens

另外,我有一个更普遍的担忧,即实际验证令牌的最佳做法是什么.假设用于 JWT 生成的秘密"被泄露(在我的场景中,很多人可能可以访问系统的源代码,但不能访问系统本身).我是否相信恶意用户可以仅使用此信息代表任何给定用户生成令牌,而无需通过 AD 进行身份验证,在我的 API 请求中使用该令牌?令牌通常使用 jwt.sign(payload, secretOrPrivateKey, options) 生成.或者,假设恶意用户可以获得一个实际的令牌(在它过期之前).对我来说,似乎不必知道用户的用户名和密码,安全性现在降低为必须知道用户名和 JWT 密码.这是一个有效的问题吗?我应该怎么做才能防止这种情况发生?

Also, I have a more general concern, regarding what the best practice is for actually verifying tokens. Suppose that the "secret" used for JWT generation is compromised (in my scenario many people may have access to the source code of the system, but not to the system itself). Am I right in believing that a malicious user could then, with only this information, generate a token on behalf of any given user, and without ever authenticating with AD use that token in my API requests? A token is typically generated using jwt.sign(payload, secretOrPrivateKey, options). Alternatively, suppose a malicious user could get hold of an actual token (before it has expired). To me it seems like instead of having to know a user's username and password, the security is now reduced to having to know the username and the JWT secret. Is this a valid concern and what should I do to prevent this?

到目前为止,我最大的希望是在登录后使用服务器端会话来存储有关当前用户的信息,这样即使在访问后端端点时恶意生成并使用了令牌,它也会失败,除非用户实际上已经离开通过登录路由,通过 AD 进行身份验证,并因此在会话中存储了一些信息.

My best hope so far is using a server side session to store information about the current user after logging in, so that even if a token is maliciously generated and used when accessing backend endpoints, it would fail unless the user has actually gone through the login route, authenticated with AD and stored some information in the session as a result of this.

我还考虑过在 each API 端点中实际使用 AD 进行身份验证,但这需要在每个请求中发送 AD 用户名/密码,这反过来又需要敏感信息必须是存储在客户端的会话存储或本地存储中,这很可能是个坏主意.

I also considered actually authenticating with AD in each API endpoint, but that would require the AD username/password to be sent in every request, which in turn would require that sensitive information would have to be stored in the client's sessionstorage or localstorage, which is most likely a bad idea.

所以,问题:

1) 将 AD 授权与 JWT 结合作为不记名令牌是否合理,或者使用 AD 进行身份验证构建安全后端 + 前端的首选方式是什么?

1) Is it reasonable to combine AD authorization with JWT as bearer token or what is the preferred way to build a secure backend + frontend utilizing AD for authentication?

2) 如果 JWT 是一个好主意,那么使用 JWT 保护端点的最佳实践是什么?使用服务器端会话合理吗?

2) If JWT is a good idea, what is the best practice for securing endpoints using JWT? Is using a server side session reasonable?

有趣的是,我发现了大量关于如何最好地实现基于令牌的身份验证的示例(一般而言,或特别是使用 NodeJS),但其中许多似乎以某种方式存在缺陷.

Interestingly enough I have found tons of examples on how to best implement token based authentication (in general, or with NodeJS specifically), but many of them seem flawed in one way or another.

推荐答案

1) 将AD授权与JWT结合为承载是否合理令牌或构建安全后端的首选方法是什么+前端使用 AD 进行身份验证?

1) Is it reasonable to combine AD authorization with JWT as bearer token or what is the preferred way to build a secure backend + frontend utilizing AD for authentication?

这是合理的,但如果您已经在使用 Kerberos 和 AD 对用户进行初始身份验证,您可以考虑使用 s4u2proxy 约束委派 允许服务向 KDC 提供用户的服务票证并获取(根据授权检查)后端服务票证(并重复多次服务是必要的).

It is reasonable, but if you are already using Kerberos and AD to initially authenticate the user, you might consider using s4u2proxy constrained delegation which allows the service to present the user's service ticket to the KDC and acquire (subject to authorisation checks) a ticket for a backend service (and repeat for as many services are necessary).

如果您有很多需要联系的后端服务,则单个 JWT 可能会承载所有服务执行授权策略所需的所有授权声明更好的选择.

If you have a lot of backend services that need to be contacted, a single JWT bearing all the authorization claims needed for all the services to enforce authorization policy may be a better option.

2) 如果 JWT 是一个好主意,那么确保安全的最佳实践是什么使用 JWT 的端点?使用服务器端会话合理吗?

2) If JWT is a good idea, what is the best practice for securing endpoints using JWT? Is using a server side session reasonable?

适用一般密钥安全做法:

General key security practices apply:

  • 永远不要在任何地方的非易失性存储器中明文存储密钥.
  • 理想情况下,不要将加密密钥存储在服务器上的附加存储中,如果服务器遭到入侵,它们将受到离线攻击.仅在服务器启动时使它们对主机可用.
  • 确保密钥材料驻留在安全内存中,这样就无法将其交换到磁盘(和/或使用加密交换).
  • 使用公钥算法,这样多个主机上就不需要存在密钥.
  • 考虑使用硬件安全模块 (HSM).
  • Never store keys in the clear in non-volatile storage, anywhere.
  • Ideally do not store encrypted keys in attached storage on the server where, if the server is compromised, they would be subject to offline attack. Make them available to the host only at server startup.
  • Ensure key material resides in secure memory so that it cannot be swapped to disk (and/or use encrypted swap).
  • Use public key algorithms so that no secret key need exist on multiple hosts.
  • Consider using a hardware security module (HSM).

这篇关于在 NodeJS 后端使用 JWT 和 Active Directory 身份验证的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆