Twitter API, oAuth, STOMP Protocol

4,658 views

Published on

Blogcocktail Dev Team Aug. 2009 Worksthop
By Seira

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,658
On SlideShare
0
From Embeds
0
Number of Embeds
271
Actions
Shares
0
Downloads
73
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Twitter API, oAuth, STOMP Protocol

  1. 1. Twitter API / oAuth Seira, templar@blogcocktail
  2. 2. Twitter API
  3. 3. 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
  4. 4. Things Every Developer Should Know... ● Pagination limits ● REST API : 3200 status ● Search API : 1500 status ● Encoding ● HTML entities
  5. 5. 인증방식 ● Basic Authentication ● HTTP 기본적인 인증방식 ● 어플리케이션이 비밀번호를 저장하거나 읽어야 함 . ● Base64 인코딩을 하나 , 네트워크에 패스워드가 노 출 ● 공식블로그의 blogcocktail@twitter 에서 이 방식 사용 ● oAuth ● 매시업 어플리케이션을 위한 좀 더 강화된 인증방식 ● 이 부분에 대해서는 뒤에서 더 자세하게 다룸
  6. 6. 보안 이슈 ● 패스워드 저장 ● 저장하지 말고 oAuth 를 쓰라고 강력히 권고 ● Basic Authentication 은 곧 폐지 (deprecated) 될 것임 ● SSL ● 트위터는 모든 REST API 에 SSL 을 지원 ● 민감한 API 호출시 SSL 연결을 지원할 것을 권고 ● 데스크탑 Apps ● 패스워드 저장시 암호화 서비스 사용 권고 (keyChain, keyring)
  7. 7. 앞으로의 트위터 API ● Retweet API 의 지원 ● statuses/home_timeline ● statuses/retweeted_by_me ● statuses/retweeted_to_me ● statuses/retweets_of_me ● statuses/retweet ● Streaming API ● 아직 알파테스트중 ● Geolocation API
  8. 8. oAuth
  9. 9. oAuth 란 ? ● 매시업 어플리케이션이 다른 서비스의 API 를 호출 하기 위해서는 사용자의 권한을 가지고 있어야 함 . ● 이를 위해서 App Key 나 심지어 ID/PW 를 매시업 어플리케이션이 저장해야 하는 것이 문제 ● 이를 해결하기 위한 새로운 인증 방식 ● 공개 표준 ● Google AuthSub, Yahoo! BBAuth 등과 비교 ● 이들 서비스의 베스트 프랙티스를 모아 만들었 음
  10. 10. oAuth 를 발렛 키에 비유 ● oAuth 는 당신이 사용하는 모든 웹서비스에 대한 발렛 키다 . ● 발렛 키는 당신의 차를 주차할 수 있을 정도의 권한만 제공하지 , 트렁크를 열거나 2 마일 이 상 운전하거나 RPM 의 빨간 선까지 속도를 내 는 권한은 없다 . ● 마찬가지로 , OAuth 키는 웹 에이전트가 당신 의 웹 메일을 체크하는 기능만 제공하며 , 당 신인 것처럼 해서 주소록에 있는 모든 사람에 게 메일을 보내는 일은 하지 못하게 한다 .
  11. 11. oAuth 인증에 관여하는 객체 ● Service Provider(SP) ● 인증이 필요한 서비스를 제공하는 사이트 ● User ● SP 에 인증을 할 수 있는 자격이 있는 사용자 ● Consumer ● User 가 SP 의 데이터를 공유하길 원하는 사이 트 , Apps ● 사전에 SP 와 Consumer 는 신뢰 관계를 맺고 있어야 함
  12. 12. Oauth 인증에 관여하는 객체 ● Protected Resources ● Consumer 가 인증을 통해 SP 로부터 제공받 고자 하는 데이터 ● Tokens ● 비밀번호 (credentials) 대신 인증을 위한 키 ● 임의의 문자열로 보통 구성되어 있음
  13. 13. 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 을 응답
  14. 14. oAuth 인증 프로세스 ● Consumer 는 인증을 획득하기 위해 SP 의 인증 URL 로 사용자를 유도 ● 이 때 request token 를 함께 보냄 ● 또한 callback URL 을 보낼 수 있음 ● 사용자는 SP 에 ID/PW 로 인증 ● 인증 과정은 Consumer 는 전혀 관여하지 않음 ● SP 는 request key 를 획득한 consumer 의 접근을 허락할 것인지를 사용자에게 물어보고 , 이를 승인 하면 해당 request key 를 승인 . ● callback URL 이 있다면 사용자를 유도
  15. 15. oAuth 인증 프로세스 ● Consumer 는 이제 인증된 자원에 접근하기 위해 Request Token 을 Access Token 으로 바꾸어 줄 것을 요청함 ● SP 는 요청을 분석하고 Access Token 및 Access Token Secret 을 응답함 ● Access Token 을 받은 Consumer 는 이제 인 증된 자원에 접근할 수 있음
  16. 16. oAuth 인증시 보안 ● 앞에 설명한 oAuth 인증 프로세스에서는 Token 및 secret 키의 무결성과 부인방지를 위한 방법이 생략 되었음 ● 이를 위해 , 보안 연결 (HTTPS) 을 사용할 수 있음 ● 하지만 HTTPS 는 설치 및 유지보수에 진입장벽이 높음 ● 기본적으로 oAuth 는 비보안 연결을 위해 디자인되 었다고 언급하고 있음 ● 비보안 연결을 위해 signing requests 를 할 것 을 명시하고 있음
  17. 17. 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 파라미터를 함께 보내도록
  18. 18. 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]))
  19. 19. 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
  20. 20. 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
  21. 21. Bonus : STOMP protocol
  22. 22. Streaming Text Orientated Messaging Protocol ● 스트리밍 메시지를 효과적으로 전송하기 위 한 프로토콜 ● Client / Message Broker ● TCP 를 기반으로 동작함 (SSL 포함 ) ● HTTP 와 유사한 방식 (coming from the HTTP school of design), 매우 간단한 프로토콜 ● http://stomp.codehaus.org/ 에서 오픈소스 프로젝트로 진행중 ● ActiveMQ 와 같은 잘 알려진 메시지 브로커에 서 지원
  23. 23. STOMP Connect Command - client request - - server response - CONNECT CONNECTED login: <username> session: <session-id> passcode:<passcode> ^@ ^@
  24. 24. STOMP Client Command ● SEND : 메시지 전송 ● SUBSCRIBE : 메시지 큐 구독 ● UNSUBSCRIBE : 메시지 큐 구독 해지 ● BEGIN : 트랜잭션 시작 ● COMMIT : 트랜잭션 커밋 ● ABORT : 트랜잭션 롤백 ● ACK : 큐에서 온 메시지에 응답 (acknowledge) ● DISCONNECT : 연결 종료
  25. 25. SEND/SUBSCRIBE SEND SUBSCRIBE destination:/queue/a destination: /queue/foo ack: client hello queue a ^@ ^@
  26. 26. UNSUBSCRIBE/BEGIN UNSUBSCRIBE BEGIN destination: /queue/a transaction: <transaction- identifier> ^@ ^@
  27. 27. COMMIT/ABOUT COMMIT ABORT transaction: <transaction- transaction: <transaction- identifier> identifier> ^@ ^@
  28. 28. ACK/DISCONNECT ACK DISCONNECT message-id: <message- identifier> ^@ transaction: <transaction- identifier> ^@
  29. 29. Rececipt header ● 클라이언트가 보내는 특정 명령에 서버가 어 떤 응답을 남기길 원하는 경우에 사용하는 헤 더 SEND destination:/queue/a receipt:message-12345 Hello a!^@
  30. 30. Sever Frame ● MESSAGE : 메시지를 담은 프레임 ● RECEIPT : receipt 헤더가 있는 프레임을 받았 을 경우에 응답해주는 프레임 ● ERROR : 에러 내용을 담은 프레임
  31. 31. MESSAGE/RECEIPT ACK RECEIPT MESSAGE receipt-id:message-12345 destination:/queue/a message-id: <message- ^@ identifier> hello queue a^@
  32. 32. 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. ^@

×