我正在为我的 API 实现服务器端 OAuth。我在这里看到 Google 允许完整的 javascript 编写的应用程序使用它的 API。
在这种情况下，因为我们在“查看源”环境中，我们没有使用客户端密码，因此我们无法确定应用程序的身份。
示例：如果我看到 Google 的完整 JavaScript 应用程序，我只需要查看源代码，获取客户端密钥，然后在我自己的网站上放置代码的编辑版本。如果用户在第一个网站上接受了应用程序，我将能够使用他的数据（由于应用程序被接受，用户将完全看不到接受部分）。
即使用户必须重新接受该应用程序，如果他接受它，我将拥有第一个应用程序身份的访问权限。
我对这种方法有点害怕，我很惊讶谷歌没有在文档中暴露不同的风险，也没有在授权阶段暴露出不同的风险。我一定错过了什么……你能帮帮我吗？
我不太确定我是否让我可以理解，但如果您有任何问题，请提出。
（对不起我的英语）
你说的对。在您的应用程序中可见的数据是client id和client secret。当用户对您的应用程序进行身份验证时，您将获得一个access token您必须用于以下 API 请求的文件。访问令牌通常存储在本地数据库中，并且对于每个用户都是唯一的（甚至可能过期）。
后果：有权访问的邪恶用户必须client id重新client secret接受应用程序才能访问它。他无法直接访问它，因为他没有access token. 但接受后，他可以访问所有数据。
解决此问题的一种方法是在服务器端执行授权。您的服务器执行初始授权并存储access token. 当您想从客户端访问 API 时，您可以access token从服务器（通过安全连接）获取 API，并且您应该能够正常使用 API，并且您的client id和client secret被隐藏。实现这一点的一个简单方法是Yahoo Query Language。
我也很担心它，我读了很多书来适应它。实际上，有很多网络服务器允许纯 JavaScript 访问（例如 facebook、google、mercadolibre）。
这些公司要求您提供有效的域服务器名称，即您的客户端 ID 和客户端密码仅在您的 Web 应用程序请求时才可用。也就是说，我（太）舒服了一点。伪造您的应用程序并非易事，您 11 岁的侄子将很难尝试。
无论如何，我知道您可以对浏览器使用某种网络钓鱼攻击，让他们相信您在“your-app-domain.com”中。我不确定上述这些公司如何过滤这种攻击。
思考：我有一个想法，您可以将您的凭据存储在 cookie 中。在您的应用程序开始时使用 REST URI 并将您的凭据存储在那里。只要我知道几乎没有黑客访问cookie是可能的，但这将是一个额外的障碍。
思考 2：我不是移动开发人员，所以我一直在问：如何在移动应用中解决这个问题。即使知道反编译应用程序并不容易，但还是可以做到的。
我不知道如何解决/适应客户端凭证存储，但我希望为这次讨论做出贡献。