검색결과 리스트
글
OAuth의 개념과 대략적인 흐름
네트워크로그
2010. 12. 31. 19:41
OAuth 란 인증과정을 거쳐야 된다는 것을 알게되었다. 트위터 뿐만이 아니라, 스프링 노트와 페이스북 등 대부분의
웹서비스에서 OAuth를 사용하여 써드파티들이 데이터에 접근할 수 있도록 되어 있었다. 각 웹서비스에서는 OAuth 인증과정을
나름대로 설명해주고 있지만, 그 정보만을 가지고 구현하기는 생각보다 쉽지 않아보였다. 공개된 많은 소스와 OAuth 스펙을 참고
하여 나름대로 정리해 보았다. SNS 써드파티에 관심있는 사람들에게 조금이라도 도움이 되었으면 한다.
OAuth
OAuth 는 Open Authorization 의 약자로 API를 사용하여 자원에 접근하기 위한 오픈 표준이다. 즉
SNS 와 같은 웹서비스에 있는 자원(데이터)을 사용자의 인증정보 없이도 써드파티에서 사용할 있도록 하기위한 오픈 표준이다. 사용자의 아이디와 비밀번호를 통한 명시적인 인증정보 대신 사용자가 개인자원에 접근을 허용했다는 표시인 토큰을 발행하여, 써드파티에서 접근할 수 있게하는 것이다.
OAuth 프로토콜은 2007년 초반경에 처음 초안이 작성되어 2010 년 4월에 RFC 5849 : The OAuth 1.0 Protocol 로 등록이 되었다.
OAuth를 통해 써드파티에서 궁극적으로 획득하는 것은 사용자의 자원에 대한 접근허용을 표시하는 액세스 토큰이다.
이점을 염두하고 자주 언급되는 용어에 대해 알아보자. 트위터를 예로 들어 설명하겠다.
OAuth 용어
Service Provider : 서비스 프로바이더는 자원을 제공하는 웹서비스를 의미한다. 트위터 또는 페이스북 서비스를 의미한다.
Consumer : 서비스 프로바이터의 자원에 접근하는 써드파티 웹사이트/애플리케이션을 의미한다.
Protected Resource : 트윗글과 팔로워 목록과 같은 서비스 프로바이더가 보유한 데이터를 의미한다.
Consumer Key/Secret : 서비스 프로바이더는 자신들의 서비스에 써드파티들이 접근할 수 있도록 하는데, 이때 각 써드파티들을 고유하게 식별하기 위한 값이 Consumer Key 이며, 그에 대한 확인을 위한 값이 Consumer Secret 이다. (아이디/비밀번호와 유사)
Request Token : 액세스 토콘과 교환하기 위한 사용자의 승인이 떨어지지 않은 토큰이다. 토큰은 key와 secret으로 구성된다.
Access Token : 사용자에 의해 승인된 토큰으로, 이 토큰을 소유하면 해당사용자의 자원을 사용할 수 있게 된다.
OAuth Parameter : OAuth 인증을 위해 필요한 파라미터 값으로, oauth_ 라는 접두어로 시작한다.
OAuth 의 간략한 흐름
크게 3가지 단계로 나눌 수 있다.
① ServiceProvider 가 제공하는 Request token URL에 접속하여, Request Token을 요청하여 얻는다.
이 값은 Access Token과 교환하기 위한 값이며, 아직은 사용자의 승인이 되지 않은 토큰 값이다.
② ServiceProvider 가 제공하는 Authorize URL에 접속하면서 Request Token 값을 전달하면, 사용자의 인증페이지를
볼수 있게된다. 사용자가 (로그인을 하고) 접근허용을 하면, Verifier 값을 얻을 수 있게된다.
(이 때, Consumer 가 웹서비스 또는 애플리케이션인지에 따라 Verifier 값을 다르게 수신하게 된다.
웹서비스라면, ServiceProvider 에게 제공한 callback 주소로 리다이렉트 되면서 Verifier가 전달되며,
애플리케이션이면, 리다이렉션 없이 pincode를 발급해준다. 이 pincode를 추출하여 Verifier 로 사용한다. )
③ ServiceProvider 가 제공하는 Access token URL로 접속하여, Request Token 과 Verifier를 함께 전달하면
Access Token을 얻을 수 있게된다.
④ 획득한 Access Token을 사용자의 계정에 따라 저장하여, 이후에 자원에 접근하기 위한 값으로 사용할 수 있다.
OAuth 인증과정은 4가지 과정으로 단순하다. 하지만 인증과정을 어렵게 보이게 하는 것은 ②번 과정을 제외한 나머지
과정에서 URL 요청시 적절한 oauth 파라미터 값들을 생성하여, 보내주어야 하기 때문이다. 이 하나하나 파라미터 값들을
올바로 생성하기 위해서는 ServiceProvider 와 스펙에서 요구하는 사항을 준수하여야 한다. 지금은 세부 사항들은 무시하고,
크게 4가지 단계를 거치게 된다는 것만 이해하자. 위 흐름을 간략히 그림으로 나타내 보았다.
사용자의 계정별로 ①,②,③ 번 과정은 한번만 수행하면 되며, 이후 ④ 을 조회하기 위해 사전에 획득한 Access Token을
사용하게 된다. (물론 ServiceProvider에 따라 Access Token을 특정기간 동안에만 유효하게 할 수 있는데, 그럴 경우 일정주기마다
①,②,③ 번 과정을 다시 거쳐야 한다. )
지금까지 OAuth 의 개념과 대략적인 흐름을 알아보았다. 다음 포스팅에서는 각 단계별로 필요한 oauth 파라미터들과 파라미터를
생성하는 방법, 그리고 실제 구현까지 해보겠다.
'네트워크로그' 카테고리의 다른 글
| [FTP] (2) 클라이언트 구현하기 (0) | 2011.03.09 |
|---|---|
| [FTP] (1) FTP(File Transmission Protocol) 프로토콜 이해 (0) | 2011.03.09 |
| 바이트 오더링(byte ordering) (0) | 2011.03.08 |
| OAuth의 세부사항 (0) | 2011.01.01 |
| OAuth의 개념과 대략적인 흐름 (0) | 2010.12.31 |
