与this issue和this (setCodeVerifier) API in AppAuth
有关
似乎我们不能仅设置代码挑战，而忽略AppAuth身份验证代码流的代码验证器部分，这阻止了以下流程涉及带有移动应用程序和相关后端的服务：
- 移动应用程序请求访问后端服务器API
- 后端服务器拒绝登录
- 后端服务器创建PKCE代码质询和代码验证程序
- 后端服务器将代码质询（但不是验证程序）与后端服务器Oauth2 clientId一起发送到移动应用程序
- 移动应用通过后端服务器和后端服务器clientId提供的代码质询执行授权代码授予
- 移动应用将身份验证代码发送回后端服务器（请注意，没有验证程序，没有人拥有获取访问/ ID令牌的所有权限）
- 后端服务器现在仅通过其知道访问/ ID令牌的身份与代码验证程序交换身份验证代码，并在后端上创建用户会话
- 现在，访问/标识令牌可以发送回移动应用程序，以与Google的API一起使用，以及用于委派对应用程序后端服务器的访问控制。就是我们的移动应用程序与后端服务器之间的通信使用与用于保护我们的后端服务与Google资源服务器之间的通信相同的访问/ ID令牌来保护。
以上链接的stackoverflow问题表示，在使用后端的客户端机密的情况下，不需要PKCE，但这仍然可以从身份验证密钥拦截中打开移动应用程序。除非我没有什么遗漏，否则上面建议的流程不会只为后端服务器提供获取访问/ ID令牌的功能，同时仍使用户能够在本机应用程序中获得Oauth2的所有好处吗？
使用当前的AppAuth API或我在任何地方都可以找到的任何其他库，这似乎是不可能的。我错过了什么吗？基本上，您可以将移动应用程序视为后端服务器（真正的客户端应用程序）的前端Oauth2登录UI。
谢谢。
为了进一步参考，我正在寻找的设计属性使我发现如下：
- 后端Web服务器支持的移动应用程序
- 使用授权码流登录Google Oauth2
- 通过PKCE进行身份验证代码保护
- 跨客户端共享令牌（从技术上讲，只有一个客户端，因此我想将本机移动应用程序和后端描述为两个组件客户端（共享Oauth2身份验证代码流责任和生成的令牌）更加准确）
- 单个ClientId（后端服务器）
- 即使在后端也无需ClientSecret