我正在编写一些代码来获取Twitter和Instagram的Feed。在我编写任何代码之前，我一直希望能够很好地理解oAuth，因为我有这种唠叨的感觉，它并不是那么安全，而且大多数时候，例如在访问公共推文时，这是一个不必要的问题。我开始阅读oAuth 2 specification以便更好地理解，我仍然处于中间位置。我有很多问题。
我们以Twitter为例。 用户访问您的网站。您将它们重定向到Twitter进行身份验证并获取authorization_grant代码。 我理解这部分是安全的，因为用户身份验证和重定向到您的网站将通过ssl发生。 Twitter是否足以支持SSL，或者您的网站是否还必须支持SSL才能使重定向更加安全？您不希望授权代码被不安全地转移，对吧？
现在您拥有了authorization_grant代码，您的网站将向Twitter发送请求以获取访问令牌。发出此请求时，您的网站将发送authorization_grant代码，您的客户端ID和客户端密码。我再次猜测通信是安全的，因为这将发生在ssl上。但是，如果该网站在其HTML或Javascript中包含客户端ID和秘密，尤其是如果它是没有服务器端代码的静态站点，该怎么办？ 重定向网址是否始终由服务器端代码处理，服务器端代码应该在不通过HTML或Javascript的情况下发出访问令牌请求？
一旦您拥有访问令牌，您就会将其包含在您的请求中以获取用户的推文，代表他们发布推文等。再次，如果相关网站要在其HTML或JavaScript中包含访问令牌以及客户端ID和秘密，这将是非常不安全的，对吗？
oAuth的所有安全性似乎源于ssl和客户端保密客户秘密的能力。我在这个结论中是对的吗？
另一件事 - 在流程的第一步，当客户端将用户重定向到Twitter以进行身份验证并获取authorization_grant代码时，他们可以发送他们的客户端ID和密码并直接获取访问令牌而不是秒请求。我认为这就是规范中隐含方法的含义。 那么，为什么这个额外的步骤是发送第二个请求来获取规范中添加的访问令牌？它会增加安全性吗？
答案 0 :(得分：1)
我不确定twitter API，我正在谈论stackexchange API https://api.stackexchange.com/docs/authentication
我再次猜测通信是安全的，因为这会发生 超过ssl。但是，如果该网站包含客户端ID和秘密，该怎么办？ 在HTML或Javascript中的某个地方，特别是如果它是静态站点 没有服务器端代码？
client_secret 仅在显式流的情况下发送。服务器端应用程序应使用显式流程，并应注意保持client_secret的安全。
那么，为什么要发送第二个获取请求的额外步骤呢？ 在规范中添加了访问令牌？
嗯，隐式流的安全性低于显式流，因为访问权限会发送给用户代理。但是，除非您已将范围指定为 no_expiry ，否则在隐式流的情况下属性将过期，除非您已将范围指定为范围。服务器端流程也只能由注册的应用程序使用
似乎oAuth的所有安全性都源于ssl和客户端 能够保密客户的秘密。我是对的 结论
再次 client_secret 将在服务器端流程中可用。但是，是的，客户应该注意没有发出access_token
查看此link。它提供了 ouath 中可能存在漏洞的示例。