什么是移动应用程序的正确 OAuth 2.0 流程

Question

我正在尝试在使用 OAuth 2.0 的移动应用程序的 Web API 中实现委托授权。根据规范，隐式授权流程不支持刷新令牌，这意味着一旦在特定时间段内授予访问令牌，一旦令牌过期或被撤销，用户必须再次授予应用程序权限。

我想这对于在浏览器上运行的一些 javascript 代码来说是一个很好的场景，正如规范中提到的那样。我试图尽量减少用户必须授予应用程序权限以获取令牌的时间，因此看起来授权代码流是一个不错的选择，因为它支持刷新令牌。

但是，此流程似乎严重依赖 Web 浏览器来执行重定向。我想知道如果使用嵌入式 Web 浏览器，此流程对于移动应用程序是否仍然是一个不错的选择。还是我应该使用隐式流程？

Answer 1

澄清：移动应用 = 原生应用

正如其他 cmets 和一些在线资源中所述，隐式似乎很适合移动应用，但最佳解决方案并不总是明确的（实际上不推荐使用隐式，原因如下所述）。

原生应用 OAuth2 最佳实践

无论您选择哪种方法（需要考虑一些权衡），您都应该注意此处概述的使用 OAuth2 的原生应用的最佳实践：https://www.rfc-editor.org/rfc/rfc8252

考虑以下选项

隐式

我应该使用隐式吗？

引用第 8.2 节https://www.rfc-editor.org/rfc/rfc8252#section-8.2

OAuth 2.0 隐式授权授权流程（在 OAuth 2.0 [RFC6749] 第 4.2 节中定义）通常适用于在浏览器中执行授权请求并通过基于 URI 的应用间通信接收授权响应的做法。 但是，由于 PKCE [RFC7636]（第 8.1 节要求）无法保护隐式流，不建议将隐式流与本机应用程序一起使用。

通过隐式流程授予的访问令牌在没有用户交互的情况下也无法刷新，从而使授权代码授予流程- 它可以发出刷新令牌——对于需要刷新访问令牌的本机应用授权来说，这是更实用的选择。

授权码

如果您确实使用授权代码，那么一种方法是通过您自己的 Web 服务器组件进行代理，该组件使用客户端密码丰富令牌请求，以避免将其存储在设备上的分布式应用程序中。

以下摘自：https://dev.fitbit.com/docs/oauth2/

建议将授权代码授予流程用于以下应用程序： 有一个网络服务。此流程需要服务器到服务器的通信 使用应用程序的客户端密码。

注意：切勿将您的客户端机密放入分布式代码中，例如应用程序 通过应用商店或客户端 JavaScript 下载。

没有网络服务的应用程序应该使用隐式 拨款流程。

结论

在对入围的方法进行适当的风险评估并更好地了解其影响后，最终决定应考虑您所需的用户体验以及您对风险的偏好。

在这里阅读精彩 https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

另一个是https://www.oauth.com/oauth2-servers/oauth-native-apps/，它表示

当前行业最佳实践是使用授权流程 同时省略客户端密码，并使用外部用户代理 完成流程。外部用户代理通常是设备的 本机浏览器，（与本机应用程序具有单独的安全域，） 使应用程序无法访问 cookie 存储或检查或修改 浏览器内的页面内容。

PKCE 考虑

您还应该考虑这里描述的 PKCE https://www.oauth.com/oauth2-servers/pkce/

具体来说，如果您还实现了授权服务器，那么https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ 声明您应该这样做

• 允许客户端为其重定向 URL 注册自定义 URL 方案。
• 支持具有任意端口号的环回 IP 重定向 URL 以支持桌面应用程序。
• 不要假设原生应用程序可以保密。要求所有应用声明它们是公开的还是机密的，并且只向机密应用发布客户端机密。
• 支持 PKCE 扩展，并要求公共客户端使用它。
• 尝试检测授权界面何时嵌入到本机应用的 Web 视图中，而不是在系统浏览器中启动，并拒绝这些请求。

网页浏览量注意事项

有很多使用 Web 视图的示例，即嵌入式用户代理，但应避免使用这种方法（尤其是当应用程序不是第一方时），并且在某些情况下可能会导致您被禁止使用 API正如下面来自here 的摘录所示

任何嵌入 OAuth 2.0 身份验证页面的尝试都将导致 您的应用程序被 Fitbit API 禁止。

出于安全考虑，OAuth 2.0 授权页面必须是 呈现在专用的浏览器视图中。 Fitbit 用户只能确认 他们正在使用真正的 Fitbit.com 网站进行身份验证，如果他们有 浏览器提供的工具，例如 URL bar 和 Transport 层安全 (TLS) 证书信息。

对于原生应用，这意味着授权页面必须打开 在默认浏览器中。本机应用程序可以使用自定义 URL 方案 作为重定向 URI 将用户从浏览器重定向回 申请许可。

iOS 应用程序可以使用 SFSafariViewController 类而不是 应用程序切换到 Safari。 WKWebView 或 UIWebView 类的使用是 禁止。

Android 应用程序可能会使用 Chrome 自定义选项卡而不是应用程序 切换到默认浏览器。禁止使用 WebView。

为了进一步澄清，这里引用了this section 以上提供的最佳实践链接的先前草案

嵌入式用户代理，通常通过网络视图实现，是一种 授权本机应用程序的替代方法。然而他们是 根据定义，第三方使用不安全。它们涉及用户 使用他们的完整登录凭据登录，只是为了让他们 缩小到功能较弱的 OAuth 凭据。

即使由受信任的第一方应用程序使用，嵌入式用户代理 通过获得更大的权力来违反最小特权原则 凭据比他们需要的多，可能会增加攻击面。

在典型的基于 Web 视图的嵌入式用户代理实现中， 主机应用程序可以： 将表单中输入的每个按键记录到 捕获用户名和密码；自动提交表单并绕过 用户同意；复制会话 cookie 并使用它们来执行 以用户身份进行身份验证的操作。

鼓励用户在嵌入式 Web 视图中输入凭据，而无需 浏览器具有的常用地址栏和其他身份功能 使用户无法知道他们是否正在登录 合法网站，即使他们是，它也会训练他们没关系 无需先验证网站即可输入凭据。

除了安全问题，网络视图不共享 与其他应用程序或系统浏览器的身份验证状态，需要 用户登录每个授权请求并导致 用户体验差。

由于上述原因，不建议使用嵌入式用户代理， 除非受信任的第一方应用程序充当外部用户 - 其他应用程序的代理，或为多个首次提供单点登录 派对应用。

授权服务器应该考虑采取措施来检测和阻止 通过不属于他们自己的嵌入式用户代理登录，其中 可能。

这里也提出了一些有趣的观点：https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the-a

Answer 2

很遗憾，我认为这个问题没有明确的答案。但是，以下是我确定的选项：

• 如果可以询问用户他/她的凭据，则使用Resource Owner Password Credentials。但是，由于某些原因，这可能是不可能的，即

  • 可用性或安全策略禁止直接在应用中插入密码
  • 身份验证过程委托给外部身份提供者，并且必须通过基于 HTTP 重定向的流程（例如 OpenID、SAMLP 或 WS-Federation）执行

• 如果需要使用基于浏览器的流程，请使用Authorization Code Flow。在这里，redirect_uri 的定义是一个重大挑战，有以下选择：

  • 使用https://developers.google.com/accounts/docs/OAuth2InstalledApp 中描述的技术，其中特殊的redirect_uri（例如urn:ietf:wg:oauth:2.0:oob）向授权端点发出信号以显示授权代码，而不是重定向回客户端应用程序。用户可以手动复制此代码，也可以让应用尝试从 HTML 文档标题中获取。
  • 在设备上使用localhost 服务器（端口管理可能不容易）。
  • 使用自定义 URI 方案（例如 myapp://...），在取消引用时会触发已注册的“处理程序”（详细信息取决于移动平台）。
  • 如果可用，请使用特殊的“网络视图”（例如 Windows 8 上的 WebAuthenticationBroker）来控制和访问 HTTP 重定向响应。

希望对你有帮助

佩德罗

Answer 3

TL;DR：将授权码授予与PKCE一起使用

1.隐式授权类型

隐式授权类型在移动应用中非常流行。但它不应该像这样使用。重定向存在安全问题。 Justin Richer states:

当您意识到与远程服务器不同时，问题就来了 URL，没有可靠的方法来保证a之间的绑定 给定的重定向 URI 并尊重特定的移动应用程序。任何 设备上的应用程序可以尝试将自己插入重定向 进程并使其提供重定向 URI。猜猜看：如果 你已经在你的原生应用程序中使用了隐式流，那么你 只是把你的访问令牌交给了攻击者。没有恢复 那一点 — 他们已经拿到了令牌，他们可以使用它。

再加上它不允许你刷新访问令牌，最好避免它。

2。授权码授予类型

授权码授予需要客户端密码。但是您不应该在移动应用程序的源代码中存储敏感信息。人们可以提取它们。为了不暴露客户端机密，您必须以Facebook writes 的身份运行服务器作为中间人：

我们建议应用访问令牌只能直接从 您的应用程序的服务器，以提供最佳的安全性。对于本地人 应用程序，我们建议该应用程序与您自己的服务器通信，并 然后服务器使用应用程序向 Facebook 发出 API 请求 访问令牌。

不是一个理想的解决方案，但有一种新的、更好的在移动设备上进行 OAuth 的方法：代码交换的证明密钥

3.带有 PKCE（代码交换证明密钥）的授权代码授予类型

克服了这些限制，我们创建了一种新技术，让您可以在没有客户端密码的情况下使用授权代码。您可以阅读完整的RFC 7636 或this short introduction。

PKCE (RFC 7636) 是一种保护不使用公共客户端的技术 客户机密。

它主要用于本地和移动应用程序，但该技术可以 也适用于任何公共客户。它需要额外的 授权服务器支持，因此仅支持 某些提供商。

来自https://oauth.net/2/pkce/

Answer 4

在您的移动应用程序中使用 webview 应该是在 Android 平台上实现 OAuth2.0 协议的一种经济实惠的方式。

至于redirect_uri 字段，我认为http://localhost 是一个不错的选择，您不必在应用程序中移植HTTP 服务器，因为您可以覆盖WebViewClient 类中onPageStarted 函数的实现，并且检查url 参数后，停止从http://localhost 加载网页。

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

Answer 5

最流畅的身份验证用户体验和最容易实现的方法是在您的应用中嵌入 webview。处理 webview 从身份验证点收到的响应并检测错误（用户取消）或批准（并从 url 查询参数中提取令牌）。 我认为你实际上可以在所有平台上做到这一点。我已经成功地完成了以下工作：ios、android、mac、windows store 8.1 应用程序、windows phone 8.1 应用程序。我为以下服务执行此操作：dropbox、google drive、onedrive、box、basecamp。对于非 Windows 平台，我使用的是 Xamarin，据说它不会公开整个平台特定的 API，但它确实公开了足够多的内容以使这成为可能。因此，即使从跨平台的角度来看，它也是一个非常易于使用的解决方案，而且您不必担心身份验证表单的 ui。