对于移动应用程序来说，OAuth 2.0的正确流程是什么

Question

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

Answer 1

澄清：手机App=原生App

正如其他评论和一些在线消息来源所述，隐式似乎很适合移动应用程序，但最好的解决方案并不总是一目了然（事实上，出于下面讨论的原因，隐式不被推荐）。

原生应用OAuth2最佳实践

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

OAuth2.0隐式授权授权流（定义在OAuth2.0[RFC6749]4.2节中）通常适用于在浏览器中执行授权请求并通过基于URI的应用程序间通信接收授权响应的实践。
但是，由于隐式流不能受到PKCE[RFC7636]（这在8.1节中有要求）的保护，因此不建议在本机应用程序中使用隐式流。

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

授权代码

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

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

下面是https://auth0.com/blog/oauth-2-best-practions-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/声明您应该

null

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

出于安全考虑，OAuth2.0授权页面必须显示在专用的浏览器视图中。Fitbit用户只有在拥有浏览器提供的工具（如URL栏和传输层安全(TLS)证书信息）的情况下，才能确认他们正在通过正版Fitbit.com站点进行身份验证。

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

嵌入式用户代理通常通过Web视图实现，是授权本机应用程序的一种替代方法。然而，根据定义，它们对第三方使用是不安全的。它们涉及到用户使用完整的登录凭据进行登录，只是将它们的范围缩小到功能不太强大的OAuth凭据。

即使被可信的第一方应用程序使用，嵌入式用户代理也会通过获得比它们所需的更强大的凭据来违反最小特权原则，从而可能增加攻击面。

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

授权服务器应该考虑采取步骤，在可能的情况下检测并阻止通过不是它们自己的嵌入式用户代理进行的登录。

这里还提出了一些有趣的问题:https://security.stackexchange.com/questions/179756/why-are-developers-using-embedded-user-agents-for-third-party-auth-what-are-the-a