我正在尝试在使用OAuth 2.0的移动应用程序Web API中实现委托授权。根据规范，隐式授予流程不支持刷新令牌，这意味着一旦为特定时间段授予了访问令牌，用户必须在令牌过期或被撤销后再次向应用程序授予权限。
根据规范，对于在浏览器上运行的一些JavaScript代码来说，这似乎是一个不错的场景。我试图最小化用户必须授予应用程序以获得令牌的次数，因此看起来授权码流程是一个很好的选择，因为它支持刷新令牌。
然而，这个流程似乎严重依赖于用于执行重定向的Web浏览器。如果使用嵌入式Web浏览器，我想知道这个流程是否仍然是适合移动应用程序的好选择。还是我应该选择隐式流程？
澄清：移动应用程序 = 原生应用程序
正如其他评论和一些在线来源所述，隐式似乎是移动应用程序的自然选择，但最佳解决方案并不总是明确的（实际上，由于下面讨论的原因，隐式不被推荐）。
原生应用程序 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的应用间通信接收授权响应的做法相结合。授权码
如果您选择授权码，则一种方法是通过自己的Web服务器组件代理，使用客户端密钥丰富令牌请求，以避免将其存储在设备上分布式应用程序中。
摘自：https://dev.fitbit.com/docs/oauth2/
授权码授权流程适用于具有 Web 服务的应用程序。此流程需要使用应用程序的客户端密钥进行服务器之间的通信。Web视图注意事项
在野外有很多使用Web视图（即嵌入式用户代理）的示例，但应避免使用此方法（特别是当应用程序不是第一方时），在某些情况下可能会导致您被禁止使用API，如here所示。
任何试图嵌入OAuth 2.0认证页面的尝试都将导致您的应用程序被禁止使用Fitbit API。出于安全考虑，OAuth 2.0授权页面必须在专用浏览器视图中呈现。只有通过浏览器提供的工具（如URL栏和传输层安全性（TLS）证书信息），Fitbit用户才能确认他们正在与真正的Fitbit.com网站进行身份验证。对于本机应用程序，这意味着授权页面必须在默认浏览器中打开。本机应用程序可以使用自定义URL方案作为重定向URI，以将用户从浏览器重定向回请求权限的应用程序。iOS应用程序可以使用SFSafariViewController类而不是切换到Safari。禁止使用WKWebView或UIWebView类。Android应用程序可以使用Chrome自定义选项卡，而不是切换到默认浏览器。禁止使用WebView。为进一步澄清，这里是上面提供的最佳实践链接的先前草案的this section引用。很遗憾，我认为这个问题没有明确的答案。然而，以下是我所确定的选项：
如果可以要求用户提供他/她的凭据，则使用Resource Owner Password Credentials。然而，由于以下原因，这可能不可行：
如果需要使用基于浏览器的流程，则使用Authorization Code Flow。在这里，redirect_uri的定义是一个主要的挑战，有以下选项：
redirect_uri（例如urn:ietf:wg:oauth:2.0:oob）向授权端点发出信号，显示授权代码而不是将其重定向回客户端应用程序。用户可以手动复制此代码，或者应用程序可以尝试从HTML文档标题中获取它。localhost服务器（端口管理可能不容易）。myapp://...），当解引用时会触发注册的“处理程序”（详细信息取决于移动平台）。希望这有所帮助
Pedro
TL;DR: 使用带有PKCE的授权码许可进行身份验证。
1. 隐式授权类型
隐式授权类型在移动应用程序中非常受欢迎。但它并不是为这种情况而设计的。重定向存在安全问题。Justin Richer指出：
问题在于，与远程服务器URL不同，在给定的重定向URI和特定移动应用程序之间没有可靠的方法来确保绑定得到尊重。设备上的任何应用程序都可以尝试将其插入重定向过程并导致其提供重定向URI。猜猜怎么着：如果您已在本机应用程序中使用了隐式流程，则刚刚把访问令牌交给了攻击者。从那一点开始就没有恢复了-他们拥有了令牌，可以使用它。
再加上它不允许您刷新访问令牌，最好避免使用它。
2. 授权码授权类型
授权码授权需要客户端密钥。但是，您不应该将敏感信息存储在移动应用程序的源代码中。人们可以提取它们。为了不暴露客户端密钥，您必须作为中间人运行服务器，如Facebook所述：
我们建议只从应用程序服务器直接使用应用访问令牌以提供最佳安全性。对于本机应用程序，我们建议应用程序与您自己的服务器通信，然后服务器使用应用访问令牌向Facebook发出API请求。
虽然这不是理想的解决方案，但现在有一个更好的方法来在移动设备上执行OAuth：证明代码交换（PKCE）。
3. 使用PKCE的授权码授权类型
通过克服限制，创建了一种新技术，使您可以在没有客户机密的情况下使用授权码。您可以阅读完整的RFC 7636或此简短介绍。http://localhost是一个不错的选择，你不必在应用程序内部端口HTTP服务器，因为你可以重写WebViewClient类中的onPageStarted函数的实现，并在检查url参数后停止从http://localhost加载网页。public void onPageStarted(final WebView webView, final String url,
final Bitmap favicon) {}
在应用程序中嵌入Webview是实现最流畅的用户身份验证体验和最容易的方法。处理从身份验证点接收到的Webview响应，并检测错误（用户取消）或批准（并从URL查询参数中提取令牌）。 我认为你可以在所有平台上实现这一点。我已经成功地将其应用于以下平台：iOS、Android、Mac、Windows Store 8.1应用程序、Windows Phone 8.1应用程序。我为以下服务执行了此操作：Dropbox、Google Drive、OneDrive、Box、Basecamp。对于非Windows平台，我使用的是Xamarin，它据说不会公开整个特定于平台的API，但它公开了足够的内容使其成为可能。因此，即使从跨平台的角度来看，这也是一个相当可访问的解决方案，您不必担心身份验证表单的UI。