security - Oauth2 - 客户端凭证流中的长期 token 与重新身份验证

标签 security rest oauth-2.0 access-token 2-legged

我们使用 OAuth2 保护 REST 服务器的安全,并为我们控制的多个客户端应用实现了客户端凭据授权类型。现在,我们面临着要么使 token 长期存在(即它们“永不”过期)的决定,要么让客户端经常重新验证(取决于刷新) token 过期)。第一个意味着捕获的 token 可能被恶意方使用,第二个意味着经常暴露客户端 secret ,然后可以使用该 secret 来获取 token 。

资源服务器到客户端服务器身份验证中哪个更安全? 如果我们怀疑被盗, token 和客户端 key 都可能会失效。显然,所有通信都是通过 https 完成的..

目前我们认为客户端 key 比 token 更强大,因此长期存在的 token 应该更适合这种两条腿的场景。 (对于我们即将实现的任何三足授权类型,我们更喜欢使用短期 token 作为用户 session )。

感谢您的想法!

最佳答案

根据the specification客户端凭据流仅适用于不存在客户端 key 被盗风险的客户端:

The client credentials grant type MUST only be used by confidential clients.

因此,如果您将此流程与不受信任的平台上的应用程序结合使用,您绝对应该重新考虑此决定。

只要您的平台可信,就无需担心客户端 key 被盗。然后,您的决定将权衡攻击者使用被盗的访问 token 的时间与重新身份验证的额外开销(仅 one call ,但仍然有一点延迟)。当两个参与者都受信任并且您使用良好的传输层安全性来抵御 MITM 攻击时,重新身份验证步骤本身就不是客户端 secret 暴露的问题。

另请注意,它是 not recommended (也是不必要的)将刷新 token 客户端凭据流程结合使用:

A refresh token SHOULD NOT be included.

关于security - Oauth2 - 客户端凭证流中的长期 token 与重新身份验证,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14315777/

相关文章:

security - 如何保护 HTML5 中的 localStorage?

android - Http Get 在 Android 2.2 中不起作用

c# - C# 代码中的 RESTful Web 服务

java - 使用 Spring OAuth2 资源服务器和对称 key 时如何避免 KeyLengthException

https - 从 HTTP 到 HTTPS 的 POST 安全吗?

security - 如何在不重新启动的情况下关闭DEP(数据执行保护)?

security - 如何设计一个考虑安全的应用程序?

java - 除了方法之外还使用 header 将请求路由到带注释的方法

oauth-2.0 - Google OAuth2中的签名中的JWT "invalid_grant"

具有多个客户端的 Azure APIM 和 oAuth 2.0