移动应用究竟是如何通过 PKCE 实现授权码流的？答案

【问题标题】：How exactly do mobile apps achieve authorization code flow with PKCE?移动应用究竟是如何通过 PKCE 实现授权码流的？
【发布时间】：2020-04-04 22:54:08
【问题描述】：

让我们想象一下：

我使用 Xamarin（iOS/Android 兼容）开发了一个移动应用程序
我希望它通过 PKCE 支持 OAuth2 + OpenID 连接的授权代码流，以便用户的凭据永远不会存储在设备上，而是存储在访问令牌上。该令牌授予对用于使整个移动应用运行的 API 的访问权限，这意味着移动应用只是一个前端界面/UI。
我的移动应用程序被视为“客户端应用程序”还是“资源所有者”？

第三步让我很难掌握这一点。如果它被认为是客户端应用程序，将如何跟踪整个代码流，保护我们免受任何事情的影响，因为大多数东西都是可见的（移动应用程序是公共客户端，没有反向通道）

如果它被认为是资源所有者，那么这是否意味着我必须推出一个完整的专用后端，与我的 API、我的授权服务器分开，并且只针对移动应用程序（它将是“客户端应用程序”）？

如果有人可以对此有所了解，请告诉我。标题不是很正确，如果可以编辑以更好地适应这个问题，我将非常感谢。

【问题讨论】：

【解决方案1】：

您的移动应用程序是客户端应用程序 - 在授权服务器中配置了信任条目。 PKCE 由移动应用程序生成用于 2 条消息的运行时密钥：

请参阅my article 中的步骤 4、7 和 8，以了解 PKCE 消息。

移动 OAuth 涉及集成 AppAuth 库，这并不容易，但一旦完成，您将拥有最佳的安全性和可用性。

我有一个sample Android app and article，您可以轻松运行它。

iOS 上的行为类似。

【讨论】：

我正在阅读following implementation of OAuth2 for mobile apps，据我所知，移动应用程序需要有一个重定向 uri，指向它自己？这甚至可能吗？流程是这样的：移动应用程序重定向到浏览器，浏览器执行魔法，浏览器将授权码返回给移动应用程序，移动应用程序将其交换为访问令牌，它可以安全地存储在自己身上。过期了会打开浏览器，整个过程还要重复一遍？（记下用户和登录等）
是的 - 这非常正确。重定向 URL 是一个值，例如 com.mycompany.myapp:/callback，表示私有 URI 方案。重定向使用应用内浏览器，例如 Chrome 自定义选项卡（在 Android 上）。一个好的起点是运行 AppAuth 示例 - 我上面的博客有一些关于如何做到这一点的文章。