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

Question

背景

• 我们开发了一个Web应用程序,其中包含使用oauth2/oidc的rest-api以及对第三方应用程序的支持
• 我们为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//组合。Google 不会信任您/您的应用程序，为任意用户提供令牌，而无需先询问这些用户。正如您在 (1) 中提到的，用户只需要经历一次。应用程序可以检索长期刷新令牌并继续使用它来刷新访问令牌。client_secretredirect_uri

因此，最佳实践是生成浏览器/网络视图并处理其中的身份验证/同意流程。没有办法解决这个问题。如果有办法的话，它就是一个漏洞，因为系统的设计就是为了避免它。