【问题标题】:Do you generate a state parameter back or front end for an OAuth 2.0 request?您是否为 OAuth 2.0 请求生成状态参数后端或前端?
【发布时间】:2019-05-13 04:10:50
【问题描述】:

我一直在网上搜索答案,但找不到明确的答案。 由于我不太了解 CSRF 攻击,并且 OAuth 2.0 中的 state 参数是为了避免这种攻击,我只是想知道是否需要在客户端生成 state 参数并将值放在本地存储或后端服务器,然后将其存储到会话变量中,然后我返回到客户端以创建我的 URL。第一个解决方案似乎是最好的,但它安全吗?

非常感谢任何帮助。

【问题讨论】:

    标签: oauth-2.0 google-signin openid-connect


    【解决方案1】:

    更多关于state参数可以从this answer找到。

    在哪里生成状态以及在哪里存储取决于您的应用程序的性质。无论客户端类型如何,客户端必须做的是验证授权码响应中的状态参数。

    对于不包含后端的单页应用程序,必须生成状态并将其存储在浏览器本身中。一旦响应到达,就必须比较状态值。

    对于本机应用程序(例如:移动应用程序),状态可以存储在应用程序内存中。它可以附加在授权请求中。当响应到来时,可以从内存中验证它

    如果应用程序需要,可以将状态存储在后端(例如:服务器)。这可以被认为更安全(与 SPA 相比),因为除了请求本身之外没有人可以拦截/获取值。一旦发生重定向,后端可以验证响应参数。此外,它还可用于关联客户端会话。

    此外,窃取状态值仅对试图进行 CSRF 攻击的一方有价值。但请注意生成无法猜测的状态值。进一步阅读存储 - 3.6. "state" Parameter

    【讨论】:

    • 非常感谢我使用 Angular 这样一个单页应用程序的这个 anwser。我仍然有一个后端服务器,所以我可以有一个函数从后端服务器(谷歌应用程序引擎 JAVAEE)中获取生成的状态,然后将其插入客户端单击的 URL,然后将其比较到服务器端。这会是一个好习惯吗?非常感谢。
    • 如果您查看此文档 - tools.ietf.org/html/rfc6819#section-5.3.5 它提到使用会话 cookie 的哈希作为状态。如果您不希望从后端执行任何进一步的验证,您可以简单地使用这种方法。这完全取决于您的设计。
    • 好的,非常感谢,我会看看什么是最好的,不确定是否理解所有内容,但我会尝试找出(会话 cookie 的哈希)我也不太明白是什么阻止我使用我的后端验证系统正如我告诉你的那样,我需要最后比较后端的值(会话变量与 url 参数相比)。对不起,我不太了解,但我是网站建设新手。最佳
    猜你喜欢
    • 2020-03-28
    • 2018-10-12
    • 1970-01-01
    • 2012-08-19
    • 2019-07-24
    • 1970-01-01
    • 2011-08-27
    • 2014-10-05
    • 2019-04-19
    相关资源
    最近更新 更多