메인 콘텐츠로 건너뛰기

​
서명 생성하기

이 페이지에서는 HTTP 요청에 대한 OAuth 1.0a HMAC-SHA1 서명을 생성하는 방법을 설명합니다. 이 서명은 요청에 권한 부여하기에 설명된 대로, 권한이 부여된 요청의 일부로 X API에 전달하는 데 적합합니다. 예제로 사용하는 요청은 https://api.x.com/1.1/statuses/update.json 에 대한 POST 요청입니다. 원본 요청은 다음과 같습니다. 
POST /1.1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Content-Length: 76
Host: api.x.com

status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21
요청 메서드와 URL 수집 서명을 생성하려면 먼저 요청의 HTTP 메서드와 URL을 파악합니다. 이 두 값은 요청을 생성할 때 이미 알 수 있는 값이므로 쉽게 확인할 수 있습니다. X API 요청의 경우 요청 메서드는 거의 항상 GET 또는 POST입니다.
HTTP MethodPOST
기본 URL은 쿼리 문자열이나 해시 매개변수를 제외한, 요청이 전송되는 대상 URL입니다. 여기서 올바른 프로토콜을 사용하는 것이 중요하므로, URL의 https:// 부분이 API에 실제로 전송되는 요청과 일치하는지 확인해야 합니다.
Base URLhttps://api.x.com/1.1/statuses/update.json

​
매개변수 수집

다음으로, 요청에 포함된 모든 매개변수를 수집합니다. 이러한 추가 매개변수가 있을 수 있는 위치는 두 곳입니다. 하나는 URL(쿼리 문자열의 일부)이고, 다른 하나는 요청 본문입니다. 샘플 요청에는 두 위치 모두에 하나의 매개변수가 포함되어 있습니다: 
POST /1.1/statuses/update.json?include_entities=true HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.4.4
Content-Type: application/x-www-form-urlencoded
Content-Length: 76
Host: api.x.com

status=Hello%20Ladies%20%2b%20Gentlemen%2c%20a%20signed%20OAuth%20request%21
HTTP 요청에는 URL로 인코딩된 파라미터가 포함되지만, 서명을 위해서는 인코딩 전 원본 값(raw value)을 수집해야 합니다. 요청 파라미터에 더해, 모든 oauth_* 파라미터도 서명에 포함되어야 하므로 함께 수집해야 합니다. 다음은 요청 승인(authorizing a request)에서 가져온 파라미터입니다:
statusHello Ladies + Gentlemen, a signed OAuth request!
include_entitiestrue
oauth_consumer_keyxvz1evFS4wEEPTGEFPHBog
oauth_noncekYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg
oauth_signature_methodHMAC-SHA1
oauth_timestamp1318622958
oauth_token370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
oauth_version1.0
이 값들은 나중에 사용할 하나의 문자열로 인코딩되어야 합니다. 이 문자열을 만드는 절차는 다음과 같이 매우 구체적입니다:
  1. 서명에 포함될 모든 키와 값을 퍼센트 인코딩합니다.
  2. 인코딩된 키 기준으로 파라미터 리스트를 사전식(알파벳순)으로 정렬합니다 [1] [2].
  3. 각 키/값 쌍에 대해 다음을 수행합니다.
  4. 인코딩된 키를 출력 문자열에 추가합니다.
  5. ‘=’ 문자를 출력 문자열에 추가합니다.
  6. 인코딩된 값을 출력 문자열에 추가합니다.
  7. 남아 있는 키/값 쌍이 더 있다면, ‘&’ 문자를 출력 문자열에 추가합니다.  
[1] OAuth 사양에는 사전식(lexicographical) 정렬을 하라고 명시되어 있으며, 이는 많은 라이브러리에서 기본 알파벳 정렬 방식입니다. [2] 인코딩된 키가 동일한 파라미터가 둘 이상 있는 경우, OAuth 사양은 값을 기준으로 정렬을 계속하라고 명시합니다. 그러나 X는 API 요청에서 중복 키를 허용하지 않습니다.   파라미터 문자열 위에서 수집한 파라미터에 대해 이 단계를 반복하면 다음과 같은 파라미터 문자열이 생성됩니다:
statusHello Ladies + Gentlemen, a signed OAuth request!
include_entitiestrue
oauth_consumer_keyxvz1evFS4wEEPTGEFPHBog
oauth_noncekYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg
oauth_signature_methodHMAC-SHA1
oauth_timestamp1318622958
oauth_token370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb
oauth_version1.0

​
시그니처 베이스 문자열 생성

지금까지 수집한 세 개의 값은 하나의 문자열로 결합해야 하며, 이 문자열을 기반으로 시그니처가 생성됩니다. OAuth 사양에서는 이 문자열을 시그니처 베이스 문자열이라고 부릅니다. HTTP 메서드, 베이스 URL, 파라미터 문자열을 하나의 문자열로 인코딩하려면:
  1. HTTP 메서드를 대문자로 변환하고, 출력 문자열을 이 값으로 설정합니다.
  2. 출력 문자열에 ‘&’ 문자를 추가합니다.
  3. URL을 퍼센트 인코딩하고, 이를 출력 문자열에 추가합니다.
  4. 출력 문자열에 ‘&’ 문자를 추가합니다.
  5. 파라미터 문자열을 퍼센트 인코딩하고, 이를 출력 문자열에 추가합니다.  
그러면 다음과 같은 시그니처 베이스 문자열이 생성됩니다: 
POST&https%3A%2F%2Fapi.x.com%2F1.1%2Fstatuses%2Fupdate.json&include_entities%3Dtrue%26oauth_consumer_key%3Dxvz1evFS4wEEPTGEFPHBog%26oauth_nonce%3DkYjzVBB8Y0ZFabxSWbWovY3uYSQ2pTgmZeNu2VS4cg%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1318622958%26oauth_token%3D370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb%26oauth_version%3D1.0%26status%3DHello%2520Ladies%2520%252B%2520Gentlemen%252C%2520a%2520signed%2520OAuth%2520request%2521
파라미터 문자열은 반드시 퍼센트 인코딩해야 합니다. signature base string에는 정확히 앰퍼샌드 ‘&’ 문자가 2개만 포함되어야 합니다. 파라미터 문자열의 퍼센트 ‘%’ 문자는 signature base string에서 %25로 인코딩되어야 합니다.

​
서명 키 가져오기

수집해야 할 마지막 데이터는 요청을 보내는 X app과, 요청이 대리로 수행되는 사용자를 식별하는 비밀 값들입니다. 이 값은 매우 민감한 정보이므로 절대로 다른 사람과 공유해서는 안 됩니다. X에서 앱을 식별하는 값은 consumer secret이라고 하며, Developer Console에서 app details page를 확인하면 찾을 수 있습니다. 이 값은 X app이 보내는 모든 요청에서 동일하게 사용됩니다.
Consumer secretkAcSOqF21Fu85e7zjz7ZN2U4ZRhfV3WpwPAoE3Z7kBw
애플리케이션이 대리로 동작하는 계정을 식별하는 값은 OAuth token secret이라고 합니다. 이 값은 여러 가지 방법으로 얻을 수 있으며, 해당 방법들은 모두 access token 가져오기에 설명되어 있습니다.
OAuth token secretLswwdoUaIvS8ltyTt5jkRh4J50vUPVVHtR2YPi5kE
다시 한 번 강조하지만, 이 값들은 애플리케이션 외부로 노출되지 않도록 엄격히 보호해야 합니다. 값이 유출되었다고 의심되면 토큰을 재발급하십시오(이 페이지의 토큰들은 실제 요청에서는 사용할 수 없도록 무효 처리되어 있습니다). 이 두 값은 signing key로 결합되어 서명을 생성하는 데 사용됩니다. signing key는 간단히 말해 percent encoded된 token secret입니다. request token을 가져올 때와 같이 token secret을 아직 알 수 없는 플로우도 있다는 점에 유의하십시오. 이 경우 signing key는 percent encoded된 consumer secret 뒤에 앰퍼샌드 문자 ‘&’를 이어붙여 구성해야 합니다.
Signing keykAcSOqF21Fu85e7zjz7ZN2U4ZRhfV3WpwPAoE3Z7kBw&LswwdoUaIvS8ltyTt5jkRh4J50vUPVVHtR2YPi5kE

​
서명 계산하기

마지막으로, 서명은 서명 베이스 문자열과 서명 키를 HMAC-SHA1 해시 알고리즘에 전달하여 계산합니다. 알고리즘의 세부 내용은 hash_hmac 함수에 설명되어 있습니다. HMAC 서명 함수의 출력은 바이너리 문자열입니다. 이 값은 서명 문자열을 생성하기 위해 base64로 인코딩해야 합니다. 예를 들어, 이 페이지에 제시된 베이스 문자열과 서명 키를 사용했을 때의 출력은 2E CF 77 84 98 99 6D 0D DA 90 5D C7 17 7C 75 07 3F 3F CD 4E입니다. 이 값을 base64로 변환하면 이 요청에 대한 OAuth 서명이 됩니다:
OAuth signatureLs93hJiZbQ3akF3HF3x1Bz8/zU4=