OAuth Echo
- 사용자(User) – 특정 승인된 X 애플리케이션을 통해 X를 사용하고 있는 사람
- 소비자(Consumer) – 제3자 미디어 제공자(예: 사진 공유 사이트)와 상호 작용하려는 X 애플리케이션
- 위임자(Delegator) – 제3자 미디어 제공자
- 서비스 제공자(Service Provider) – 즉, X 자체
x-auth-service-provider— 실제로 이것은 ID 위임이 전송되어야 할 영역(realm)입니다. X의 경우, 이를 https://api.x.com/1.1/account/verify_credentials.json 로 설정합니다. iOS5 기반 X 통합은 이 URL에 추가적인application_id파라미터를 추가하며, 이는x-verify-credentials-authorization에서 사용되는oauth_signature를 계산할 때도 사용됩니다.x-verify-credentials-authorization— Consumer는 OAuth를 사용해 HTTP 헤더에서 https://api.x.com/1.1/account/verify_credentials.json 를 호출할 수 있도록 필요한 모든 OAuth 파라미터를 생성해야 합니다(예: OAuth oauth_consumer_key=”…”, oauth_token=”…”, oauth_signature_method=”…”, oauth_signature=”…”, oauth_timestamp=”…”, oauth_nonce=”…”, oauth_version=”…” 와 같은 형태여야 합니다).
oauth_timestamp 가 아직 유효한 시간 내에 이루어져야 한다는 점을 명심하세요.
대안으로, 이 두 파라미터를 헤더로 보내는 대신 POST 본문에 x_auth_service_provider 및 x_verify_credentials_authorization 로 보낼 수도 있습니다. 이 경우 OAuth 서명 베이스 문자열에 파라미터를 이스케이프 처리하여 포함해야 한다는 점을 기억하세요. 이는 어떤 요청에서든 파라미터를 인코딩하는 방식과 유사합니다. 가능한 한 작업을 분리하기 위해 HTTP 헤더를 사용하는 것이 가장 좋습니다.
이 시점에서 Delegator의 목표는 미디어를 저장하기 전에 사용자가 실제로 자신이 주장하는 사람인지 확인하는 것입니다. Delegator가 업로드 메서드를 통해 위의 모든 데이터를 수신하면 이미지를 일시적으로 저장한 다음, x-auth-service-provider 헤더에 지정된 엔드포인트(이 경우 https://api.x.com/1.1/account/verify_credentials.json)를 Consumer가 x-verify-credentials-authorization 헤더에서 제공한 것과 동일한 OAuth 인증 헤더를 사용하여 호출하도록 구성해야 합니다.
OAuth Echo 모범 사례
x-auth-service-provider에서 제공된 URL을 사용하세요. 예를 들어 Apple iOS는 모든 OAuth 요청에 추가적인 application_id 파라미터를 포함하며, OAuth Echo의 각 단계에서 이 파라미터가 그대로 유지되어야 합니다.
OAuth 인가 단계에서는 x-verify-credentials-authorization의 헤더 값을 가져와, 서비스 공급자에 대한 호출 시 별도의 Authorization 헤더에 넣어야 합니다. 추가로, x-auth-service-provider에 들어 있는 값이 기대한 값이 맞는지 확인하세요.
- Service Provider가 HTTP 200을 반환하면 문제 없습니다. Delegator는 이미지를 영구적으로 저장한 뒤 URL을 생성해 반환해야 합니다.
- Service Provider가 HTTP 200을 반환하지 않으면 이미지를 폐기한 후 Consumer에게 오류를 반환해야 합니다.