목차

OAuth 2.0 알아보기

OAuth 2.0은 IFTTT를 이용한 매일의 일기와 계획 적기 프로젝트의 확장을 위해 필요한 기술입니다. 매일매일 일기를 이메일로 적는다는 발상의 전환은 스스로 생각하기에도 꽤 성공적입니다. 2013년 9월 26일에 처음 시작한 일기는 단 하루도 빠짐 없이 이 문서를 최초로 작성한 일자인 11월 17일까지 이어지고 있으니까요.

이렇게 일기를 계속 쓰다보니, 몇가지 아쉬운 점이 생겼습니다. GMail을 보다 일기 작성 및 회고에 맞는 형태로 확장시키고 싶은 생각이 들었던 것입니다. 다행히 처음 생각할 때부터 구글의 API를 이용하면 쉽게 확장이 가능하리라 생각했던 것이긴 했죠. 시간이 날 때마다 차근차근 위키에 자료를 축적하면서 차근차근 일기의 기능을 웹브라우저만이 아닌 다른 어떤 형태로 확장시키리라 생각하고 있습니다.

GMail은 현재 OAuth 2.0을 인증 수단으로 채택하고 있습니다. 그러므로 확장 기능을 구현하기 위해선 OAuth2.0에 대해 잘 알지 않으면 안되겠지요.

OAuth 2.0 용어 정리

다음 용어들은 OAuth 2.0에 사용됩니다. 반드시 숙지해두어야 합니다.

OAuth 2.0 Explained

OAuth 2.0 and the Google API Client for Python 슬라이드에 기본 개념이 잘 설명되어 있습니다.

기본적인 시나리오는 다음과 같습니다. '사용자'는 어떤 '서비스'에 가입을 해서 그 서비스를 사용합니다. 이 서비스는 API를 제공합니다. '개발자'는 이 API를 이용해서 모바일 앱 등 여러 '서드파티 어플리케이션'에 활용할 수 있습니다. 물론 서드파티 어플리케이션에서도 사용자 인증이 반드시 필요합니다. 사용자 인증은 기존의 방식과 동일하게 아이디와 비밀번호를 사용하여 인증할 수도 있습니다. 그러나 이렇게 사용자 이외의 존재가 아이디와 패스워드를 함부로 루는 것은 좋지 않습니다.

슬라이드에서 OAuth 2.0 인증 과정을 가장 잘 요약한 한 슬라이드가 아래에 있습니다.

사각형 안의 Client, Resource Owner, Authentication Server, Resource Server는 '용어 정리'에서 언급하였습니다. 그러면 각 A~F까지의 흐름을 설명해보도록 하겠습니다.

(A) Authorization Request (Client --> Resource Owner)

Client가 Resource Owner에게 사용 허가를 요청합니다. 이 과정에서 사용자(Resource Owner)는 보통 다음과 같은 요청을 보게 됩니다.

사용자는 단 한 번만 이 과정을 거치면 됩니다. 이렇게 허락한 사항은 서비스 제공자(Resource Server)에 기록되며, 사용자는 언제든지 이 권한을 제거(revoke)할 수 있습니다. 아래 그림은 Dropbox가 허용한 client들의 목록을 보여주는 예시입니다(목록이 별로 없네요). 우측의 'X' 표시를 누르면 해당 앱은 사용자의 드롭박스에 접근할 권한이 박탈됩니다.

(B) Authorization Grant (Resource Owner --> Client Owner)

사용자가 '허락' 버튼을 눌렀을 때 일어나는 과정입니다. 이제 클라이언트 앱은 Resource Server에 접근을 허락받았습니다.

(C) Authorization Grant & Client Credentials (Client --> Authentication Server)

Client는 authorization server에 접속하여 인증을 요청합니다. 이 때 resource owner는 client에게 아이디와 패스워드는 일절 알려주지 않았습니다. 그러므로 client와 authorization server의 통신 과정에서 resource owner의 아이디, 패스워드는 전혀 언급되지 않을 것입니다.

(D) Access Token (Authentication Server --> Client )

사용자의 아이디와 비밀번호 대신, authentication server는 client에게 'access token'이란 것을 발급합니다. 이 token을 이용해 client는 제한적으로 resource server에 접근할 권한을 얻습니다.

(E) Access Token (Client --> Resource Server)

Client는 드디어 access token을 이용해 resource server에 API call을 수행합니다. Access token은 제한방문출입증과 비슷한 것이어서 지정된 API만 허락되며 권한을 벗어난 동작은 허용되지 않습니다. 모든 동작이 가능한 아이디/패스워드 방식에 비해 훨씬 안전하지요.

(F) Protected Resource (Resource Server --> Client)

access token을 통해 resource server로부터 데이터를 받아 옵니다. 이 데이터는 client에서 적절히 목적에 맞게 사용됩니다.

Google OAuth 2.0 for Installed Applications 과 연결

Authentication URL 얻기

Authentication url 요청을 얻는 url은 https://accounts.google.com/o/oauth2/auth이다. 여기에 파라미터들을 적어 보내야 하는데, Forming the URL 부분을 참고하면 된다. 이 주소로 직접 사용자가 로그인을 해야 한다. GUI 방식이면 따로 웹브라우저를 띄우든지, 완전 CLI 라면 해당 URL로 접속하라는 통지를 주어야 한다.

Authentication Code

보낸 정보를 바탕으로 인증 서버에서 authentication code를 발급해준다. Google의 urn:ietf:wg:oauth:2.0:oob&의 경우라면 html tag의 title에도 이 코드가 담겨 있으니 html 코드를 분석해도 결과를 얻을 수 있다. 그러면 이 코드를 이용하여 access token을 요청할 수 있다. 토큰을 요청하는 곳의 주소는 https://accounts.google.com/o/oauth2/token. 그리고 여기에 보내는 파라미터는 Handling the response를 참고하라.

Access Token

IMAP 서버에 접근하기 위해서는 access token을 IMAP 서버와 연동해야 한다.

Refreshing

토큰이 만료된 경우 재발급을 받아야 한다. https://accounts.google.com/o/oauth2/token으로 요청/응답을 받으면 된다. 이 때 보내야 하는 데이터는 Using a refresh token을 참고하라.

참고 페이지