什么是适用于移动应用的OAuth 2.0流程

5 回答

• 21

  不幸的是，我不认为这个问题有明确的答案 . 但是，我已经确定了以下选项：

  • 如果可以询问用户他/她的凭据，那么请使用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 ）通知授权 endpoints 以显示授权代码，而不是重定向回客户端应用程序 . 用户可以手动复制此代码，或者应用程序可以尝试从HTML文档 Headers 中获取它 .

  • 在设备上使用 localhost 服务器（端口管理可能不容易） .

  • 使用自定义URI方案（例如 myapp://... ），当解除引用时触发已注册的"handler"（详细信息取决于移动平台） .

  • 如果可用，请使用特殊的"web view"（例如Windows 8上的WebAuthenticationBroker）来控制和访问HTTP重定向响应 .

  希望这可以帮助

  佩德罗

  回复于 2024-05-01T11:52:23+08:00
• -2

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

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

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

  回复于 2024-05-01T11:52:23+08:00
• 6

  TL;DR: 使用授权码授予PKCE

  1. Implicit Grant Type

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

  当您意识到与远程服务器URL不同时，没有可靠的方法来确保给定重定向URI与特定移动应用程序之间的绑定得到遵守 . 设备上的任何应用程序都可以尝试将自身插入重定向过程并使其为重定向URI提供服务 . 并猜测：如果您在本机应用程序中使用了隐式流，那么您只需向攻击者提供访问令牌即可 . 从那时起就没有恢复 - 他们已经获得了令牌，他们可以使用它 .

  并且事实上，它不会让您刷新访问令牌，更好地避免它 .

  2. Authorization Code Grant Type

  授权代码授权需要客户端密钥 . 但是，您不应将敏感信息存储在移动应用的源代码中 . 人们可以提取它们 . 要不公开客户端密钥，您必须将服务器作为中间人运行为Facebook writes：

  我们建议只应从应用程序的服务器直接使用App Access Tokens，以提供最佳安全性 . 对于本机应用程序，我们建议应用程序与您自己的服务器通信，然后服务器使用App Access令牌向Facebook发出API请求 .

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

  3. Authorization Code Grant Type with PKCE (Proof Key for Code Exchange)

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

  PKCE（RFC 7636）是一种保护不使用客户端密钥的公共客户端的技术 . 它主要由本机和移动应用程序使用，但该技术也可以应用于任何公共客户端 . 它需要授权服务器的额外支持，因此仅在某些提供程序上受支持 .

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

  回复于 2024-05-01T11:52:23+08:00
• -4

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

  回复于 2024-05-01T11:52:23+08:00
• 57

  澄清：移动应用程序=本机应用程序

  正如其他评论和在线的一些消息来源所述，隐式似乎非常适合移动应用程序，但最好的解决方案并不总是明确的（事实上，由于下面讨论的原因，不推荐隐含） .

  Native App OAuth2 Best Practises

  无论您选择哪种方法（需要考虑一些权衡），您应该注意使用OAuth2的本地应用程序中概述的最佳实践：https://tools.ietf.org/html/rfc8252

  请考虑以下选项

  Implicit

  我应该使用隐含的吗？

  引用第8.2节https://tools.ietf.org/html/rfc8252#section-8.2

  OAuth 2.0隐式授权流程（在OAuth 2.0 [RFC6749]的第4.2节中定义）通常适用于在浏览器中执行授权请求并通过基于URI的应用程序间通信接收授权响应的做法 . 但是，由于PKCE [RFC7636]（第8.1节中要求）无法保护隐式流，因此不推荐使用隐式流与本机应用程序 . 通过隐式流授予的访问令牌也无法在没有用户交互的情况下刷新，使得授权代码授权流（可以发出刷新令牌）成为需要刷新访问令牌的本机应用程序授权的更实用的选项 .

  Authorization Code

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

  摘录如下：https://dev.fitbit.com/docs/oauth2/

  对于具有Web服务的应用程序，建议使用授权代码授予流程 . 此流程需要使用应用程序的客户端密钥进行服务器到服务器通信 . 注意：永远不要将您的客户端置于分布式代码中，例如通过应用商店或客户端JavaScript下载的应用 . 没有Web服务的应用程序应使用隐式授权流程 .

  Conclusion

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

  一个很好的阅读在这里https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

  另一个是https://www.oauth.com/oauth2-servers/oauth-native-apps/，其中说明了这一点

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

  PKCE Consideration

  您还应该考虑这里描述的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 Views Consideration

  在野外有很多使用Web视图的例子，即嵌入式用户代理，但应该避免这种方法（特别是当应用程序不是第一方时），并且在某些情况下可能会导致您被禁止使用API作为摘录以下来自here演示

  任何嵌入OAuth 2.0身份验证页面的尝试都将导致您的应用程序被禁止使用Fitbit API . 出于安全考虑，OAuth 2.0授权页面必须在专用的浏览器视图中显示 . Fitbit用户只有拥有浏览器提供的工具（如URL栏和传输层安全性（TLS）证书信息）才能确认他们是否使用真正的Fitbit.com网站进行身份验证 . 对于本机应用程序，这意味着授权页面必须在默认浏览器中打开 . 原生应用可以使用自定义URL方案作为重定向URI，将用户从浏览器重定向回请求权限的应用程序 . iOS应用程序可能使用SFSafariViewController类而不是应用程序切换到Safari . 禁止使用WKWebView或UIWebView类 . Android应用程序可能会使用Chrome自定义标签而非应用切换到默认浏览器 . 禁止使用WebView .

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

  通常使用Web视图实现的嵌入式用户代理是授权本机应用程序的另一种方法 . 但是，根据定义，它们不适合第三方使用 . 它们涉及用户使用其完整登录凭据登录，只是让他们缩小到不太强大的OAuth凭据 . 即使被受信任的第一方应用程序使用，嵌入式用户代理也会通过获取比他们需要的更强大的凭据来违反最小权限原则，从而可能增加攻击面 . 在嵌入式用户代理的典型基于Web视图的实现中，主机应用程序可以：记录在表单中输入的每个击键以捕获用户名和密码;自动提交表格并绕过用户同意;复制会话cookie并使用它们以用户身份执行经过身份验证的操作 . 鼓励用户在嵌入式Web视图中输入凭据，而无需通常的地址栏和浏览器所具有的其他身份功能，这使得用户无法知道他们是否正在登录合法网站，即使是在合法网站上，也会培训他们没有先验证网站就可以输入凭据 . 除了安全问题之外，Web视图不与其他应用程序或系统浏览器共享身份验证状态，要求用户登录每个授权请求并导致糟糕的用户体验 . 由于上述原因，建议不要使用嵌入式用户代理，除非受信任的第一方应用充当其他应用的外部用户代理，或者为多个第一方应用提供单点登录 . 授权服务器应该考虑采取措施，通过可能的嵌入式用户代理检测和阻止登录 .

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

  回复于 2024-05-01T11:52:23+08:00