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

Question

背景

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

问题/问题

• 我们当然希望能够完全信任我们的原生应用，而不是显示同意屏幕以获得最佳用户体验。在使用授权代码/隐式流程时，虽然没有任何内容可被视为秘密，但如果未显示同意屏幕，则恶意黑客可能潜在地利用（无需用户知识）用户。
• 我们如何避免在确保用户尽可能安全的同时显示我们自己的原生应用的同意屏幕？

如何解决？

1. 执行单独的office365 / google登录以从此idp检索刷新令牌，然后使用此令牌实现公开身份验证的方式，以从我们的webapp检索长期令牌。
2. 简单地忽略安全漏洞，并且永远不要求用户同意，因为`clientId / clientSecret / redirectUrl`的非秘密混合，借口“很难破解这个”。
3. 如果以“google / office365”为借口进行外部登录，则无论如何都会在请求刷新令牌时显示同意屏幕时忽略安全漏洞。
4. 确保其不是恶意应用/用户的一些未知方式

我不喜欢（1）的原因是它在我们的webapp中打开了一个新的认证流程，并迫使本机应用程序实现更复杂的认证流程。

这里有什么东西我不知道，什么是最佳做法？

Answer 1

关键是Google需要对您应用以外的用户进行身份验证，以确保您的应用无法看到用户凭据，从而无法实现OAuth的目的。

用户还需要明确允许该应用，以避免随机应用从用户获取令牌：拥有Google帐户的任何人都可以创建client_id / client_secret / redirect_uri组合。 Google /您的应用不会信任任意用户的令牌，而无需先询问这些用户。正如你在（1）中提到的，用户只需要经历一次。该应用程序可能会检索一个长期存在的刷新令牌并继续使用它来刷新访问令牌。

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

Answer 2

我会说像nr 2：

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

客户秘密应该是安全的;如果不是，你还有其他安全问题。