13

显然，在使用 OAuth 1.0 时，您需要从 API 提供者那里获取消费者密钥和消费者秘密......

但是当我尝试使用 Facebook、Google Oauth 2.0 等 OAuth 2.0 API 时，我从不需要获取消费者密钥/消费者密钥（我为 Facebook 获取了 App ID 和 App 密钥，但它们与消费者密钥/消费者密钥不同我对么？）

所以我的问题是......当使用 Oauth 2.0 时，您不需要像 Oauth 1.0 那样拥有消费者密钥/消费者秘密吗？

Oauth 2.0 也不需要签名方法（HMAC-SHA1 等），对吗？HMAC-SHA1 仅与 Oauth 1.0 相关，对吗？

4

3 回答 3

15
  1. OAuth 2 提供商通常会为您的客户端/应用程序和一些秘密/密码发出标识符，OAuth 草案称这些客户端标识符和客户端密钥。这些用于检查调用是否真的由您的应用程序发出。但是，OAuth 涵盖了不同的授权授予流程，这些流程或多或少是安全的，并且并不都需要某种秘密。Google 称它们为client ID和client secret，Facebook 称它们为App ID和App Secret，但它们都是相同的。
  2. 是的，在 OAuth 2 中，所有加密步骤都移到了服务器端。
于 2012-07-31T18:05:54.850 回答
5

您所指的授权授予流程在 OAuth 2 规范中称为客户端凭据授予流程。它用于执行仅限应用程序的身份验证。这意味着没有用户参与。一个典型的例子是在主页上显示 twitter 提要。

通常，应用程序通过 HTTPS 将使用者密钥（或应用程序 ID）和使用者密码（或应用程序密码）传递给服务器。此请求仅受 HTTPS 保护；没有额外的加密。服务器返回一个令牌，您可以从那时起使用该令牌向 API 发出请求 - 因为它不需要用户上下文。

使用者密钥（或应用程序 ID）标识您的应用程序并且可能具有有意义的值。您通常不会（或不能）再更改此设置。但是，如果您认为消费者机密已被泄露，则可以重新生成消费者机密。这就解释了为什么有两个键。

重新生成消费者密钥不同于使令牌无效，如果消费者密钥和消费者密钥已被泄露，这将无济于事。

于 2015-09-13T11:56:22.433 回答
0

两者都是一样的。应用程序/用户/客户端使用的术语不同。就是这样。两者都是一样的。

于 2015-09-05T09:32:46.573 回答