带有公共客户端密钥的授权码流程是否等同于隐式流程?

问题描述 投票:0回答:1

我希望我的单页 Web 应用程序通过 OAuth 隐式流程登录 Jira。但是,Jira 只提供授权码流程。

假设我已经确定隐式流程足够安全以满足我的需求,并且我无法构建后端。

如果我将客户端密钥添加到我的客户端包中(公开公开),这在功能上是否等同于使用隐式流程?

隐式流程:

  1. 在我的应用程序中单击“使用 Jira 登录”
  2. 重定向至 Jira
  3. 登录 Jira
  4. 使用访问令牌重定向回来

授权码流程:

  1. 在我的应用程序中单击“使用 Jira 登录”
  2. 重定向至 Jira
  3. 登录 Jira
  4. 使用授权码重定向回来
  5. 浏览器使用公共客户端密钥交换访问令牌的授权代码

如果客户端密钥是公开的,则任何人都可以在第 4 步之后用授权代码交换访问令牌,但我不介意,因为在隐式流程中,我的应用程序已经拥有访问令牌。


这比隐式流程安全吗?

除了用授权代码交换访问令牌之外,客户端密钥还能用于更多用途吗?

攻击者可以利用泄露的客户端机密做哪些他们在隐式流程中无法做的事情?

oauth-2.0 oauth jira jira-rest-api
1个回答
0
投票

隐式流程之所以存在,是因为该规范是在 CORS 被主要浏览器引入和实现之前编写的。这意味着位于

myAwesomeSPA.com
的 SPA 无法直接向另一个域(例如
accounts.google.com
)的授权服务器发送 HTTP 请求。唯一的通信方式是通过浏览器重定向。这就是为什么
access_token
必须作为查询参数发送到回调 URL。

引入 CORS 后,无需在 URL 中公开

access_token
,而是会在 URL 中返回随机代码,您的 SPA 可以通过直接 HTTP POST 请求将其交换为
access_token
。这使得该过程更加安全,因为该随机代码的有效时间很短(通常不到一分钟)并且只能使用一次。所以没有任何理由再使用这种“隐式流程”。

现在回到你的问题。在我看来,您假设要使用授权代码流程,您需要有一个

client_secret
。这不是真的。您可以在没有
client_secret
的情况下与公共客户端一起使用该流程。顾名思义,授权代码流程就是关于获取代码并将其交换为
access_token
的中间步骤,而不是直接在回调重定向中直接接收
access_token

因此没有理由为公共客户端使用

client_secret
。并且没有理由使用隐式流。对于公共客户端,您应始终使用授权代码流 + 代码交换证明密钥 (PKCE)。这是大多数库默认执行的操作。有关更多信息,请参阅:基于浏览器的应用程序的 OAuth 2.0

© www.soinside.com 2019 - 2024. All rights reserved.