Embed Size (px)
DESCRIPTION
Blogcocktail Dev Team Aug. 2009 Worksthop By Seira
Citation preview
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.
^@
