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

Question

我正在用 Angular 开发 SPA 应用程序，对于实现身份验证和授权的正确方法有很多困惑。

首先，该应用程序是第一方应用程序，这意味着我正在开发授权服务器和资源服务器。

登录应用程序的用户必须拥有对其平台上资源的完全访问权限。

因此，我使用 OAuth2.0 来完成此操作，并且我对该协议的域以及安全问题有一些疑问。

第一个问题：

第一个问题是 OAuth 是否应该实际用于授权第一方应用程序。据我了解，这是一种委托协议，用于在用户同意的情况下授予第三方应用程序对平台上用户资源的受控访问权限。这如何适合第一方应用程序的环境？在这种情况下，应用程序应该获得一个访问令牌，其范围允许完全访问，对吗？

第二个问题：

由于这是一个单页应用程序，我无法在客户端存储秘密。因此，我选择使用 PKCE 的授权代码授予，这似乎适合管理这种情况。在这种情况下，我不会要求刷新令牌，但我只会检索访问令牌并使用静默检查来刷新它。我不想将刷新令牌不安全地存储在浏览器上。这个PKCE真的安全吗？该秘密是动态生成的，但攻击者最终可以使用相同的公共客户端 ID 创建一个系统并正确管理 PKCE，并最终获得一个访问令牌，在我的例子中，该令牌可以完全访问用户资源。

我将来可以允许第三方应用程序对我的应用程序资源进行受控访问，这也是我坚持使用 OAuth 的原因之一。

Answer 1

第一个问题是 OAuth 是否应该实际用于授权第一方应用程序。据我了解，这是一种委托协议，用于在用户同意的情况下授予第三方应用程序对平台上用户资源的受控访问权限。这如何适合第一方应用程序的环境？在这种情况下，应用程序应该获得一个访问令牌，其范围允许完全访问，对吗？

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

这个PKCE真的安全吗？

是的，即使没有 PKCE，authorization_code 也非常安全。添加 PKCE 解决了一些潜在的安全问题，但我有点倾向于将其称为边缘情况。这绝对是现在推荐的选择。

PKCE rfc 提供了有关 PKCE 背后动机的更多信息：

https://www.rfc-editor.org/rfc/rfc7636#section-1