外部身份验证时如何避免在我们自己的本机应用程序中显示同意屏幕？

Posted 2023-02-19

【中文标题】外部身份验证时如何避免在我们自己的本机应用程序中显示同意屏幕？

【英文标题】：How to avoid showing consent screen in our own native apps when external authentication?

【发布时间】：2015-12-30 13:50:57

【问题描述】：

背景

我们开发了一个 Web 应用程序，其中包含使用 oauth2/oidc 的 rest-api 并支持第三方应用程序 我们已经为安卓和ios开发了我们自己的原生应用。目前，他们从用户凭据流中检索长期存在的令牌（无需同意屏幕）。 我们目前正在扩展我们的身份验证流程，以接受 google/office365 的外部登录。这也可以通过在授权代码/隐式 oauth 流中指定 acr 值来支持。

问题/问题

我们当然希望能够完全信任我们的本机应用程序，而不是为了获得最佳用户体验而显示同意屏幕。在使用授权代码/隐式流程时，尽管没有任何内容可以被视为秘密，并且如果未显示同意屏幕，恶意黑客可能会利用（在用户不知情的情况下）用户。 我们如何避免必须为我们自己的原生应用显示同意屏幕，同时仍确保用户尽可能安全？

如何解决？

执行单独的 office365/google 登录以从此 idp 检索刷新令牌，然后实施一种使用此令牌公开身份验证的方法，以从我们的 web 应用检索长期存在的令牌。 考虑到 `clientId/clientSecret/redirectUrl` 的非秘密组合，以“很难破解这个”为借口，只需忽略安全漏洞，并且永远不要征求用户同意。 如果外部登录以“google/office365 在请求刷新令牌时无论如何都应该显示同意屏幕”为借口，则忽略安全漏洞。 一些未知的方法来确保它不是恶意应用/用户

我不喜欢上面的 (1) 的原因是它既在我们的 webapp 中打开了一个新的身份验证流程，又迫使原生应用程序实现更复杂的身份验证流程。

这里有什么我遗漏的吗，什么是最佳实践？

【问题讨论】：

难道没有一种类似于网络应用程序的方法吗？那么您具有相同的属性 - clientId/secret 存在于 Web 应用程序中，而本机应用程序必须以这种方式访问​​它？当然，Web 应用程序端点可能会被滥用，但普通 Web 应用程序也是如此……

这与不通过 webapp 安全性有什么不同？

安全性变得“相同”。 webapp 有自己的专用后端，可能不会公开经过身份验证的用户配置文件，具体取决于应用程序的用途。如果 webapp 公开了需要特定 clientId 的内容，那么这可能与应用程序的客户端标识一样被滥用。这可能无法解决您的问题，但如果您将应用程序视为浏览器，它们应该被视为相似。

【参考方案1】：

关键是 Google 需要在您的应用之外对用户进行身份验证，以确保您的应用看不到用户凭据，从而破坏 OAuth 的目的。

用户还需要明确允许应用程序避免随机应用程序从用户那里获取令牌：任何拥有 Google 帐户的人都可以创建 client_id/client_secret/redirect_uri 组合。 Google 不信任您/您的应用程序，在没有先询问这些用户的情况下为任意用户提供令牌。正如您在 (1) 中提到的，用户只需要完成一次。应用可能会检索长期存在的刷新令牌并继续使用它来刷新访问令牌。

因此，最佳做法是生成浏览器/webview 并在其中处理身份验证/同意流程。没有办法解决这个问题。如果有办法，这将是一个漏洞，因为系统旨在避免它。

【讨论】：

可能有点误解，我们要避免的是我们自己的应用程序使用 webview 为所有本机应用程序显示的同意屏幕。当与 google/o365 身份验证结合使用时，这将意味着每个资源（谷歌和我们）实际上都有一个同意屏幕。对于我们自行开发（且受信任）的应用程序，我们正在寻找一种方法来避免在使用外部身份验证时出现我们自己的同意屏幕。

【参考方案2】：

我会说类似 nr 2 的话：

有办法将客户端（由 clientId 和 clientSecret 标识）标记为受信任（例如，使用超级用户界面），从而自动给予同意。

客户端密码应该是安全的；如果不是，您还有其他安全问题。

【讨论】：

本地应用程序中的ClientSecret被认为是不安全的，对于其他网络应用程序我们已经这样做了。

你说得对……我更习惯于在网络应用中思考。