手动实施 Oauth2 授权码授予流程

Question

我计划手动实施 Oauth2 授权代码授予流程（使用 PKCE）。我的问题部分与this 有关。我正在使用 Java，Springboot。

我想使用 Oauth 保护我的后端 API。这些 api 由本机应用程序调用。大多数授权代码授予的 Oauth 实现都需要用户交互。我想知道是否可以避免这种情况。由于我的应用程序在本机应用程序上运行，我不希望用户被重定向到浏览器进行身份验证。我的应用程序具有注册/登录功能。

我打算实现一个过滤器，其中的逻辑看起来与此类似

if(uri contains authorize){
    get all details from request
    generate a uuid and store details in db with ttl
    return uuid as code.
}

else if(uri contains token){
    get all details from request
    extract code from request and check for validity in database.
    if(code valid) {
       generate a JWT with access_token with ttl and refresh_token
       return JWT
    }
}

else{
    check if JWT is present and valid
    if valid proceed
}

我还将有一个刷新令牌的逻辑。我想知道

1. 这样做有没有安全漏洞
2. 是否有其他替代方法可以在无需用户交互的情况下实现授权码授予流程。
3. 关于 PKCE。使用 PKCE 通过不创建/存储客户端密码来减轻授权代码被拦截的威胁。但是，是什么阻止了用户使用他/她自己的代码质询向授权端点发送请求呢？原生应用中的客户端 ID 有多安全？

Answer 1

首先

不要，我再说一遍，不要尝试自己实施某种形式的自定义安全性。

这是你能做的最糟糕的事情之一。安全性很复杂，通常需要多个团队来实施。这就是为什么我们有它的标准库。 使用弹簧安全性。

回答你的问题：

1. 安全漏洞无处不在。安全性远不止是您发布的一小段代码。 oauth2 是一个标准，对验证和检查的内容和方式有确切的规则。所以我的快速回答是肯定的，你没有遵循标准。所以是的，它是不安全的。使用弹簧安全性。

2. 不，当您说用户交互时，我不知道您在说什么。您需要遵循定义的流程，如果您选择自动化流程，这取决于您。描述您实际想要做什么。

3. ClientIds 或任何与此相关的东西在任何应用程序中都是不安全的。这完全取决于您正在寻找的安全级别。如果我们谈论的是企业安全，您通常会将所有机密存储在后端，并为您的前端应用程序实现某种 BFF，该应用程序包含所有客户端机密并执行交换。唯一存储在客户端中的是不同类型的安全 cookie。

因此，如果您选择由您的实际原生应用程序进行交换，或者某种代理服务取决于您。但是不，没有任何秘密对任何客户都是安全的。