将 OAuth 用于使用我自己的 API 的移动设备和网站的正确方法是什么？

Question

我有一个与 OAuth 2 的工作方式更相关的问题，但由于使用 IdentityServer 来实现 OAuth，我认为它是相关的。我在任何地方都找不到答案。

我正在构建一个网站和一个使用我自己的 API 的移动应用程序。我的应用程序的每个用户都有一个用户名和密码，这将使他能够访问应用程序/网站并通过 API 访问他的信息。

我不确定处理用户登录流程的正确方法：

1. 在网站上，我有自己设计的登录表单。我不想将用户移动到我的身份验证服务器进行登录，然后让他批准他提供的信息 - 他是我系统上的用户 - 我可以访问所有信息 - 像 facebook 这样的 kida 可以登录并访问信息 - 他们不会问你愿意给他们什么。那么隐式真的是这样吗？
2. 在移动应用程序上，我也有一个登录表单，现在我在这里 (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10) 读到 OAuth 方法是在 WebView 中登录？看起来 Facebook 登录不是在他们移动应用上的 WebView 中。
3. 我首先看到的方法是资源所有者。用户将登录，获取令牌和刷新令牌，并可以开始使用我的 API。但是将我的 client_id 和 secret 存储在移动应用程序上？在网站上的 javascript 文件？感觉不对。我当然可以调用一个 API 来屏蔽这些 API 并成为登录过程的代理......但是......（阅读 #4）。
4. 将来我希望允许第三方开发人员访问。为了让他们允许我系统的用户登录，我将使用隐式流程。另外，我计划让这些开发人员帐户具有受限的 API 访问权限（例如，对 API 的调用次数将受计划限制）。是什么阻止了这些开发人员在他们网站上的我的系统上询问他们帐户的用户名和密码，使用访问令牌和刷新令牌从我的服务器获取响应，并根据需要使用我的 API，不受限制，并且有权访问整个用户个人资料？
5. 假设我坚持资源所有者流程，从服务器接收回一个令牌和一个刷新令牌。我应该在移动设备上存储什么以及如何存储？什么应该存储在浏览器中以及如何存储？刷新令牌？并且每次他打开应用程序时都会使用该刷新令牌获得一个新的更新令牌？

编辑

澄清一下，因为我发现很多讲座和文章从 API 消费者（即第三方开发人员）的角度解释了该过程：我是 API 所有者和身份验证服务器所有者，我' m 用户帐户的所有者（他们是我服务的用户），我也是我自己的消费者（通过网站和移动应用程序），并且将来我希望第三方开发人员允许我的用户使用他们的我的服务帐户登录（有点像 Facebook 或 Google）

Answer 1

你是正确的，你不应该在你的应用程序中存储client_secret，但我怀疑你是否会绕过存储client_id。您也可以禁用应用程序的同意屏幕，并构建本机登录视图。如果您不希望用户每次使用您的应用程序时都登录，您需要将access_token 和refresh_token 存储在设备上（可能在数据库中加密）。

至于问题4，你可以这样做：

1. 在您的（网络）应用中嵌入client_secret
2. 设置哪些主机可以访问 IdentityServer 上的 api
3. IdentityServer 生成盐并将其发送给客户端
4. 客户端使用hash(ip_address + session_salt)计算session_secret
5. 客户端使用session_secret 和client_secret 进行API 调用
6. 服务器验证hash 和client_secret

要完全阻止某人使用您的 API 几乎是不可能的。但是你应该添加各种速率限制方法，例如限制 IP 地址、API 调用等。但是没有什么能阻止有人反编译你的应用程序并访问你的client_id。