OAuth 1.0a

Twitter 开发者平台上的许多端点都使用 OAuth 1.0a 方法来代表 Twitter 账号执行或发出 API 请求。例如,如果你有一个 Twitter 开发者应用,则只要用户对该应用进行验证,你就可以代表任何 Twitter 账号发出 API 请求。

请注意:如果不熟悉 HMAC-SHA1 和百分号编码等概念,建议查看下面的“实用工具”部分,其中列出了一些可以极大简化身份验证过程的 API 客户端。

 

重要概念

使用密钥和令牌对请求签名

 

请务必在授权标头中传递几个生成的密钥和令牌,来对每个 API 请求进行签名。首先,你可以在 Twitter 开发者应用的详细信息页面中生成多个密钥和令牌,包括以下项:

API 密钥和机密:

oauth_consumer_key

oauth_consumer_secret

在发出 API 请求时,请将它们视作代表你的 Twitter 开发者应用的用户名和密码。 

访问令牌和机密:

oauth_token

oauth_token_secret

访问令牌和访问令牌机密是特定于用户的凭据,用于验证 OAuth 1.0a API 请求。它们指定代表其发出请求的 Twitter 账号。

如果希望应用代表与开发者账号关联的同一 Twitter 账号发出请求,可以在 Twitter 开发者应用详细信息页面上生成自己的访问令牌和令牌机密。

如果想为其他用户生成访问令牌,请参阅下面的“代表用户发出请求”。

代表用户发出请求

 

创建签名时,需要一组访问令牌,用于表示将要代表其发出请求的用户。

你可以从应用详细信息页面生成一组代表 Twitter 开发者应用所属的 Twitter 账号的访问令牌,但如果想代表另一个 Twitter 账号发出请求,则该账号的所有者必须通过三方 OAuth 流程登录自己的账号,以向你授予访问权限。此过程的输出是一组可用于发出 OAuth 1.0a 请求的访问令牌(oauth_token 和 oauth_token_secret)。

有了这些密钥和令牌后,便可从头开始创建签名。但请不要这样做,除非你了解自己所做的操作,或者你在使用下面提及的某种工具向需要 OAuth 1.0a 的端点发出请求。

下面提供了一个已签名的 cURL 请求示例以供参考,其中生成的所有令牌都在授权标头中传递:

 

请注意,用户访问令牌属于敏感数据,应小心保管。生成访问令牌时,它们所代表的用户将相信你的应用程序可以确保其安全。如果 API 密钥和用户访问令牌都存在安全隐患,则应用程序可能会公开隐私信息和账号功能的访问权限。我们建议你详细了解如何保护密钥和访问令牌

实用工具

对请求进行签名的过程很复杂。我们建议你使用可自动生成大量身份验证令牌的 API 客户端库:

Postman

一种 API 客户端,你可用它来构建和发送 REST API 请求。 请阅读我们的“Postman 入门”教程,了解有关此工具的更多信息。 

Insomnia

Insomnia 是一种 REST API 客户端,具有针对 Mac、Windows 和 Linux 的 Cookie 管理、环境变量、代码生成和身份验证功能。