Twitter API, oAuth, STOMP Protocol

Twitter API / oAuth

Seira, templar@blogcocktail

Twitter API

Things Every Developer Should Know...

● Two APIs – REST API / Search API● Call Limit

● 1000 total Updates/Day● 250 total DM/Day● 150 API request/Hour

● HTTP-based, Restful● Special Parameters

● callback● suppress_response_codes

Things Every Developer Should Know...

● Pagination limits● REST API : 3200 status● Search API : 1500 status

● Encoding● HTML entities

인증방식

● Basic Authentication

● HTTP 기본적인 인증방식● 어플리케이션이 비밀번호를 저장하거나 읽어야 함 .● Base64 인코딩을 하나 , 네트워크에 패스워드가 노

출● 공식블로그의 blogcocktail@twitter 에서 이 방식 사용

● oAuth

● 매시업 어플리케이션을 위한 좀 더 강화된 인증방식● 이 부분에 대해서는 뒤에서 더 자세하게 다룸

보안 이슈

● 패스워드 저장

● 저장하지 말고 oAuth 를 쓰라고 강력히 권고● Basic Authentication 은 곧 폐지 (deprecated) 될 것임

● SSL

● 트위터는 모든 REST API 에 SSL 을 지원● 민감한 API 호출시 SSL 연결을 지원할 것을 권고

● 데스크탑 Apps

● 패스워드 저장시 암호화 서비스 사용 권고 (keyChain, keyring)

앞으로의 트위터 API

● Retweet API 의 지원● statuses/home_timeline● statuses/retweeted_by_me● statuses/retweeted_to_me● statuses/retweets_of_me● statuses/retweet

● Streaming API● 아직 알파테스트중

● Geolocation API

oAuth

oAuth 란 ?

● 매시업 어플리케이션이 다른 서비스의 API 를 호출하기 위해서는 사용자의 권한을 가지고 있어야 함 .

● 이를 위해서 App Key 나 심지어 ID/PW 를 매시업 어플리케이션이 저장해야 하는 것이 문제

● 이를 해결하기 위한 새로운 인증 방식● 공개 표준

● Google AuthSub, Yahoo! BBAuth 등과 비교● 이들 서비스의 베스트 프랙티스를 모아 만들었

음

oAuth 를 발렛 키에 비유

● oAuth 는 당신이 사용하는 모든 웹서비스에 대한 발렛 키다 .

● 발렛 키는 당신의 차를 주차할 수 있을 정도의 권한만 제공하지 , 트렁크를 열거나 2 마일 이상 운전하거나 RPM 의 빨간 선까지 속도를 내는 권한은 없다 .

● 마찬가지로 , OAuth 키는 웹 에이전트가 당신의 웹 메일을 체크하는 기능만 제공하며 , 당신인 것처럼 해서 주소록에 있는 모든 사람에게 메일을 보내는 일은 하지 못하게 한다 .

oAuth 인증에 관여하는 객체

● Service Provider(SP)● 인증이 필요한 서비스를 제공하는 사이트

● User● SP 에 인증을 할 수 있는 자격이 있는 사용자

● Consumer● User 가 SP 의 데이터를 공유하길 원하는 사이

트 , Apps● 사전에 SP 와 Consumer 는 신뢰 관계를 맺고

있어야 함

Oauth 인증에 관여하는 객체

● Protected Resources● Consumer 가 인증을 통해 SP 로부터 제공받

고자 하는 데이터● Tokens

● 비밀번호 (credentials) 대신 인증을 위한 키● 임의의 문자열로 보통 구성되어 있음

oAuth 인증 프로세스

● Consumer 가 인증되지 않은 상태에서 SP 에게 인증이 필요한 하는 자원을 요청

● SP 는 401 NotAuthorized 로 응답● 응답시 헤더에 oAuth 인증이 필요함을 명시

WWW-Authenticate: Oauth realm="http://sp.example.com/"

● 이제 Consumer 는 oAuth 로 인증하기 위해 사전에 SP 로부터 받은 Consumer key 를 가지고 요청

● SP 는 이 요청에 대해 Request Token 과 Request Secret 을 응답

oAuth 인증 프로세스

● Consumer 는 인증을 획득하기 위해 SP 의 인증 URL 로 사용자를 유도

● 이 때 request token 를 함께 보냄● 또한 callback URL 을 보낼 수 있음● 사용자는 SP 에 ID/PW 로 인증● 인증 과정은 Consumer 는 전혀 관여하지 않음

● SP 는 request key 를 획득한 consumer 의 접근을 허락할 것인지를 사용자에게 물어보고 , 이를 승인하면 해당 request key 를 승인 .

● callback URL 이 있다면 사용자를 유도

oAuth 인증 프로세스

● Consumer 는 이제 인증된 자원에 접근하기 위해 Request Token 을 Access Token 으로 바꾸어 줄 것을 요청함

● SP 는 요청을 분석하고 Access Token 및 Access Token Secret 을 응답함

● Access Token 을 받은 Consumer 는 이제 인증된 자원에 접근할 수 있음

oAuth 인증시 보안

● 앞에 설명한 oAuth 인증 프로세스에서는 Token 및 secret 키의 무결성과 부인방지를 위한 방법이 생략되었음

● 이를 위해 , 보안 연결 (HTTPS) 을 사용할 수 있음● 하지만 HTTPS 는 설치 및 유지보수에 진입장벽이 높음

● 기본적으로 oAuth 는 비보안 연결을 위해 디자인되었다고 언급하고 있음

● 비보안 연결을 위해 signing requests 를 할 것을 명시하고 있음

oAuth 의 Signing request

● oAuth 는 Customer 의 모든 요청에 oauth_signature_method 파라미터를 명시한 signing request 를 사용할 것을 명시

● 보안 연결일 경우에는 signature_method 를 PLAINTEXT 로 사용 가능

● oAuth 스펙에서는 세 가지 signature_method를 정의

● HMAC-SHA1, RSA-SHA1, PLAINTEXT● Signing request 를 위해 요청시

oauth_signature 파라미터를 함께 보내도록 함

oAuth 의 Signing request

● oauth_signature● Signature Base String 을 명시한

signature_mehtod 로 암호화 / 인코딩한 값● Signature Base String

● signature_mehtod 가 PLAINTEXT 인 경우 , parameter_encode([consumer_secret]&[token_secret])

● 그 외 HMAC, RSA 를 사용할 경우 parameter_encode(hmac_or_rsa([all_parameters]))

oAuth 의 Signing request

● All Parameters● oauth_consumer_key● oauth_token● oauth_signature_method● oauth_signature● oauth_timestamp● oauth_nonce (to prevent 'reply attack')● oauth_version (optional, default '1.0')● addtional parameters

oAuth 인증요청 응답 에러

● HTTP 400 Bad Request● Unsupported parameter● Unsupported signature method● Missing required parameter● Duplicated OAuth Protocol Parameter

● HTTP 401 Unauthorized● Invalid Consumer Key● Invalid / expired Token● Invalid signature● Invalid / used nonce

Bonus : STOMP protocol

Streaming Text Orientated Messaging Protocol

● 스트리밍 메시지를 효과적으로 전송하기 위한 프로토콜

● Client / Message Broker● TCP 를 기반으로 동작함 (SSL 포함 )

● HTTP 와 유사한 방식 (coming from the HTTP school of design), 매우 간단한 프로토콜

● http://stomp.codehaus.org/ 에서 오픈소스 프로젝트로 진행중

● ActiveMQ와 같은 잘 알려진 메시지 브로커에서 지원

● 미투데이 알리미 (Streaming) API 에 사용

STOMP Connect Command

- client request -

CONNECT

login: <username>

passcode:<passcode>

^@

- server response -

CONNECTED

session: <session-id>

^@

STOMP Client Command

● SEND : 메시지 전송● SUBSCRIBE : 메시지 큐 구독● UNSUBSCRIBE : 메시지 큐 구독 해지● BEGIN : 트랜잭션 시작● COMMIT : 트랜잭션 커밋● ABORT : 트랜잭션 롤백● ACK : 큐에서 온 메시지에 응답 (acknowledge)● DISCONNECT : 연결 종료

SEND/SUBSCRIBE

SEND

destination:/queue/a

hello queue a

^@

SUBSCRIBE

destination: /queue/foo

ack: client

^@

UNSUBSCRIBE/BEGIN

UNSUBSCRIBE

destination: /queue/a

^@

BEGIN

transaction: <transaction-identifier>

^@

COMMIT/ABOUT

COMMIT

transaction: <transaction-identifier>

^@

ABORT

transaction: <transaction-identifier>

^@

ACK/DISCONNECT

ACK

message-id: <message-identifier>

transaction: <transaction-identifier>

^@

DISCONNECT

^@

Rececipt header

● 클라이언트가 보내는 특정 명령에 서버가 어떤 응답을 남기길 원하는 경우에 사용하는 헤더SEND

destination:/queue/a

receipt:message-12345

Hello a!^@

Sever Frame

● MESSAGE : 메시지를 담은 프레임● RECEIPT : receipt 헤더가 있는 프레임을 받았

을 경우에 응답해주는 프레임● ERROR : 에러 내용을 담은 프레임

MESSAGE/RECEIPT

ACK

MESSAGE

destination:/queue/a

message-id: <message-identifier>

hello queue a^@

RECEIPT

receipt-id:message-12345

^@

ERROR

ERROR

message: malformed packet received

The message:

-----

MESSAGE

destined:/queue/a

Hello queue a!

-----

Did not contain a destination header, which is required for message propagation.

^@