OAuth

OAuth

 

트위터 관련 앱을 개발하면서 정보수집을 하는중에 트위터 서비스에 있는 특정 데이터를 사용하기 위해서는

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 파라미터들과 파라미터를

생성하는 방법, 그리고 실제 구현까지 해보겠다.

 

 

지난 포스팅에 이어 OAuth의 세부사항에 대해 알아보자

 

① Request Token 요청 / ③ Access Token 요청 / ④ Protected Resources 요청 단계에서 적절한 oauth 파라미터를 함께 전달해주어야

하는데 이 파라미터들에 대해서 알아보자. Consumer는 ServiceProvider 에게 3가지 방법 중 하나를 통해 파라미터를 전달할 수 있다.

1) HTTP 헤더에 Authorization 헤더를 통해 전달한다.

2) HTTP 헤더의 POST request body를 통해 전달한다. (이때 Content-Type 헤더는 application/x-www-form-urlencoded로 설정함)

3) URL의 쿼리 파트를 통해 전달한다.

 

어느 방법을 선택해도 되지만, 이 포스팅에서는 첫번째 방법을 설명하겠다. 전체적인 흐름을 나타낸 그림은 다음과 같다.

 

 

oauth 파라미터

oauth 파라미터는 OAuth 스펙에서 요구하는 "oauth_ " 접두어를 갖는 파라미터를 의미한다. oauth 파라미터의 종류와 그 의미는

다음과 같다.

 

oauth_version	OAuth 프로토콜의 버전으로 1.0으로 설정하며, 선택적인 파라미터 값이다
oauth_consumer_key	ServiceProvider 에서 제공하는 Consumer 를 고유하게 식별하기 위한 값
oauth_token	request token 값으로 Request token 요청시에는 사용되지 않으며, Access token 요청과 자원조회시에는 사용된다.
oauth_timestamp	GMT 1970년 1월 1일 00:00:00 이후 현재까지의 흐른 초로, 밀리초가 아닌 초 단위 임에 주의하자
oauth_nonce	reply attack 을 예방하기 위해, 동일한 timestamp 를 갖는 요청마다 유일한 랜덤값이다.
oauth_signature_method	oauth 파라미터 값들이 도중에 변경되지 않았음을 보장하기 위해 사용하는 해시 알고리즘의 종류로, HAC-SHA1, RSA-SHA1 등이 있다. 이 포스팅에서는 HAC-SHA1 를 사용한다.
oauth_signature	HMAC-SHA1 를 사용하여 생성한 알고리즘의 결과값이다. 이 알고리즘 적용에 필요한 키와 데이터에 대해서는 아래에서 자세히 다루겠다.
oauth_callback	Authorize URL 에 접속하여 사용자의 허용을 받고 리다이렉트 시킬 URL 이다. Consumer가 웹서비스가 아닌 애플리케이션이면 "oob" 로 설정해야 한다. (oob는 out of band의 약자이다.)
oauth_verifier	사용자 허용을 통해 응답받은 값으로, Access token 요청시에만 설정한다.

 

각 단계별로 필요한 파라미터들을 요약한 결과는 다음과 같다.

Request token URL 요청: oauth_consumer_key, oauth_callback, oauth_timestamp, oauth_nonce, oauth_signature_method, oauth_signature

oauth_version

Access token URL 요청: oauth_consumer_key, oauth_callback, oauth_timestamp, oauth_nonce, oauth_signature_method, oauth_signature, oauth_version, oauth_token, oauth_verifier

Protected Resources 요청: oauth_consumer_key, oauth_callback, oauth_timestamp, oauth_nonce, oauth_signature_method, oauth_signature, oauth_version, oauth_token

 

 

oauth_signature 생성하기

HAC-SHA1 해시알고리즘을 사용하여 시그너처를 생성하는 방법을 알아보자. 각 파라미터들은 percent 인코딩 또는 Base64 인코딩을 하기전에 반드시 UTF-8 로 인코딩해야함을 주의하자.

 

이 알고리즘은 키를 바탕으로 데이터에 대한 해시 값을 생성하게 되는데, data는 Signature Base String 이 되며, key 는

Consumer Secret 와 Token Secret 를 & 문자로 연결한 값이 된다.

 

HMAC-SHA1의 데이터 생성 ( Signature Base String 생성)

생성 절차는 좀 까다로운데 절차는 다음과 같다.

① oauth_signature 파라미터를 제외한 oauth 파라미터들의 키와 값을 각각 percent 인코딩을 하고 =문자로 연결한다.

(HTTP request의 post body값이 존재하면 이 값도 동일한 연산을 수행한다)

② oauth 파라미터( 키=값) 쌍을 키의 알파벳순으로 정렬한 후 &문자로 연결하여 정규화된 문자열을 생성한다

(키가 동일하면, 값의 알파벳순으로 정렬함)

③ Request URL을 percent 인코딩한다.

④ HTTP request method(대문자) 와 인코딩된 Request URL, 그리고 정규화된 문자열을 & 문자로 연결하고, percent 인코딩하여

Signature Base String을 생성한다.

 

HMAC-SHA1의 키 생성

① consumer secret를 percent 인코딩한다

② token_secret를 percent 인코딩한다. (token_secret 은 Request Token 요청시에는 공백값이며, Access Token 요청시에는

Request token의 secret이며, 자원 요청시에는 Access Token의 secret 이 된다. )

③ 인코딩된 consumer secret 값과 token secret 값을 & 문자로 연결하여 최종 데이터를 생성한다.

 

Base64 인코딩으로 바이너리 값을 아스키 값으로 변경

위에서 생성한 키와 데이터를 바탕으로 HMAC-SHA1 알고리즘을 적용하면, signature 의 바이너리 값을 얻을 수 있다.

이 데이터에 Base64 인코딩을 적용하여, 아스키코드값으로 변경하고, 다시 percent 인코딩을 적용하여 최종 signature 값을

생성한다.

 

지금까지 생성한 oauth 파라미터드를 HTTP request의 헤더에 설정하고, 요청만 하면된다. 하지만 아직 한단계가 더 남아있다.

HTTP request 의 Authorization 헤더값를 생성하는 것이다.

 

Authorization 헤더값 생성

"OAuth " (공백이 있다는 것에 주의) 문자열과 모든 oauth 파라미터의 키와 쌍따옴표로 감싼 값쌍을 =문자료 연결하고 다시 각각을 ,(쉼표)문자로 연결한다

최종헤더 값은 다음과 같은 형태일 것이다.

OAuth oauth_callback="oob", oauth_timestamp="13882494", ......

 

 

이제는 거의 마지막 과정까지 왔다. 각각 생성한 oauth 파라미터의 키와 값, Authorization 헤더의 키와 값을 HTTP 헤더에 설정하고,

http 요청을 하면 된다. HTTP 헤더와 HMAC-SHA1의 키와 데이터를 표현한 그림은 다음과 같다.

 

HMAC-SHA1 알고리즘 키와 데이터에 인코딩 적용여부는 그림에 표현하지 않았다.