背景
- 我们开发了一个网络应用程序，具有使用 oauth2/oidc 的 rest-api 并支持第三方应用程序
- 我们已经为 Android 和 iOS 开发了自己的本地应用程序。目前，他们从用户凭据流中检索长期存在的 token (不需要同意屏幕)。
- 我们目前正在扩展我们的身份验证流程，以接受通过 google/office365 进行的外部登录。这也通过在授权代码/隐式 oauth 流程中指定 acr 值来支持。
问题/问题
- 我们当然希望能够完全信任我们的原生应用，而不是为了获得最佳用户体验而显示同意屏幕。在使用授权代码/隐式流程时，虽然没有任何内容可以被视为 secret ，但如果未显示同意屏幕，恶意黑客可能会利用(在用户不知情的情况下)用户。
- 我们如何避免必须为我们自己的 native 应用显示同意屏幕，同时仍然确保用户尽可能安全？
如何解决？
- 执行单独的 office365/google 登录以从此 idp 检索刷新 token ，然后实现一种使用此 token 进行公开身份验证的方法，以从我们的网络应用检索长期有效的 token 。
- 简单地忽略安全漏洞并且从不征求用户的同意，因为 `clientId/clientSecret/redirectUrl` 的非 secret 组合与借口“很难破解这个”。
- 如果以“google/office365 在请求刷新 token 时无论如何应该显示同意屏幕”为由进行外部登录，则忽略安全漏洞。
- 一些未知的方法来确保它不是恶意应用/用户
我不喜欢上面的 (1) 的原因是它在我们的 web 应用程序中打开了一个有点新的身份验证流程，并强制 native 应用程序实现更复杂的身份验证流程。
这里有什么我遗漏的吗，什么被认为是最佳实践？
最佳答案
重点是 Google 需要在您的应用之外对用户进行身份验证，以确保您的应用看不到用户凭据，从而破坏 OAuth 的目的。
用户还需要明确允许该应用程序以避免随机应用程序从用户那里获取 token :任何拥有 Google 帐户的人都可以创建一个client_id/client_secret/redirect_uri 组合。 Google 不信任您/您的应用程序，在未先询问这些用户的情况下为任意用户提供 token 。正如您在 (1) 中提到的，用户只需要经历一次。该应用程序可能会检索长期存在的刷新 token 并继续使用它来刷新访问 token 。
因此，最佳做法是生成浏览器/ WebView 并在其中处理身份验证/同意流程。没有办法解决这个问题。如果存在某种方式，那将是一个漏洞，因为系统旨在避免它。
关于android - 外部身份验证时如何避免在我们自己的 native 应用程序中显示同意屏幕？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32905696/