创建OAuth应用程序接口时的应用程序令牌/密码
背景:我正在使用node.js和express来创建一个API。我已经在我的应用程序接口服务器中以标准的消费者/用户密钥/秘密方式实现了OAuth (与Twitter、Facebook等类似)。我希望第三方连接到我的API，同样以与这些常用API相同的方式。
通常情况下，客户端将使用应用程序令牌/密钥进行连接(例如，您作为Facebook开发人员创建了一个Facebook应用程序，并将这些应用程序提供给您)。但是，有时客户端无法为应用程序提供秘密，因为代码是以不安全的方式实现的。具体来说，我指的是Javascript库。例如，开发人员不想在Javascript代码中暴露他们的应用程序秘密，因为它是纯文本，可能会被恶意用户读取。
我注意到Facebook避免了这个问题。开发人员只需要向Javascript库提供一个应用程序令牌(而不是秘密)。我不明白如何在不从根本上使我的库不安全的情况下为我的API提供类似的选项。也就是说，如果Javascript客户端库向OAuth发出请求，而没有提供安全可靠的令牌/密钥，那么这些请求是如何由Javascript API进行身份验证的呢？
从理论上讲，我能想到的最好的解决方案是通过HTTPS连接在Javascript客户端库和API服务器之间进行某种类型的令牌传递，以便返回一个密钥供该库使用。不过，我不太确定如何确保这种移交的安全性，以防止欺骗。
回答 1
Stack Overflow用户
发布于 2012-07-10 02:23:47
在大多数情况下，遵循标准比实现一些自定义方式更好。OAuth2指定4 methods in the latest draft (28)来执行授权授权流程。隐式流程就是您在Facebook上看到的流程。
正如标准所说的那样：
在隐式授权流期间发布访问令牌时，授权服务器不会对客户端进行身份验证。在某些情况下，可以通过用于将访问令牌传递给客户端的重定向URI来验证客户端身份。访问令牌可以向资源所有者或具有对资源所有者的用户代理的访问权的其他应用程序展示。
隐式授权提高了某些客户端(如作为浏览器内应用程序实现的客户端)的响应能力和效率，因为它减少了获取访问令牌所需的往返次数。然而，这种方便性应该与使用隐式授权的安全影响进行权衡，特别是当授权代码授权类型可用时。
它有一些安全缺陷。
但据我所知，其他方法对你不起作用，因为它们会将秘密暴露给客户端(第三方网站所有者)或资源所有者(用户)，所以你应该继续使用这个方法。
https://stackoverflow.com/questions/11400435
复制相似问题
腾讯云开发者
