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