security - Oauth2.0 适合第一方应用吗？

Question

我正在开发一个 SPA 应用程序，我对实现身份验证和授权的正确方法有很多困惑。
首先，应用程序是第一方应用程序，这意味着我正在开发授权服务器和资源服务器。
登录应用程序的用户必须对平台上的资源具有完全访问权限。
所以，我使用 OAuth2.0 来做这件事，我对协议(protocol)的域以及安全问题有一些疑问。
第一个问题:
第一个问题是是否应该真正使用 OAuth 来授权第一方应用程序。据我了解，这是一种委托(delegate)协议(protocol)，用于在用户同意的情况下授予第三方应用程序对平台上用户资源的受控访问权限。这如何适合第一方应用程序的上下文？在这种情况下，应用程序应该获得一个访问 token ，其范围允许完全访问，对吧？
第二个问题:
由于这是一个单页应用程序，我无法在客户端存储 secret 。所以我选择使用 PKCE 的授权代码授予，这似乎适合管理这种情况。在这种情况下，我不会要求刷新 token ，但我只会检索访问 token 并使用静默检查来刷新它。我不想将刷新 token 不安全地存储在浏览器上。这个 PKCE 真的安全吗？ secret 是动态生成的，但攻击者最终可以使用相同的公共(public)客户端 ID 创建一个系统并正确管理 PKCE，并最终获得一个访问 token ，在我的情况下，它可以完全访问用户资源。
将来我可以允许第三方应用程序对我的应用程序资源的受控访问，这也是我坚持使用 OAuth 的原因之一。

Answer 1

The first question is if OAuth should be actually used to authorize first party applications. From my understanding this is a delegation protocol used to grant a third-party application controlled access to the user's resources on the platform, upon user consent. How does this fit in the context of a first-party app? In that case the app should get an access token with a scope that allows full access, right?

是的，这对我来说很有意义。我们跳过了我们自己的应用程序的“授予权限”步骤。

Is this PKCE really secure?

是的，即使没有 PKCE，authorization_code 也是相当安全的。添加 PKCE 解决了一些潜在的安全问题，但我更倾向于将它们称为边缘情况。现在绝对是推荐的选择。
PKCE rfc 提供了有关 PKCE 背后动机的更多信息:
https://www.rfc-editor.org/rfc/rfc7636#section-1