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

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

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

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

• Resource Owner: 서비스를 이용하고자 하는 사람들, 즉 '사용자'입니다.
• Resource Server: Resource Owner가 사용하는 서비스를 제공하는 서버측입니다. API를 제공하는 곳입니다.
• Authorization Server: 인증을 위해 필요한 서비스입니다. Resource server와 동일할 수 있습니다.
• Client: API를 활용하는 웹페이지, 모바일 웹, 데스크탑 프로그램 등의 서드 파티 어플리케이션입니다.

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

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

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

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

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

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

• The OAuth 2.0 Authorization Protocol draft-ietf-oauth-v2-22
• OAuth Community Site
• Using OAuth 2.0 for Login
• Google APIs Client Library for Python
• OAuth 2.0 – Open API 인증을 위한 만능 도구상자: 이 페이지는 한국어로 OAuth2.0을 잘 정리했습니다. 만약을 대비해 전문을 PDF로 만들어 첨부하였습니다. oauth2.0.pdf