사용자 관점에서 본 OAuth 인증과정
본 문서는 사용자 관점에서 본 OAuth 인증과정을 설명하며, OAuth 공식 홈페이지의 Getting Started Part-2 의 내용을 기반으로 작성되었습니다.
OAuth는 실제 예제로 잘 설명될 수 있습니다. OAuth스팩에 있는 Appendix A와 유사한 예제이지만, 스팩에서는 HTTP 호출 문법에 촛점을 맞춘 반면, 여기에서는 사용자, 컨수머, 그리고 서비스 프로바이더 의 관점에서 OAuth세션을 중심으로 설명합니다.
Jane은 2주동안 스코트랜드의 여행을 마치고 돌아왔습니다. Jane은 여행을 하며 찍은 사진들을 친구들과 공유하고 싶습니다. Jane은 여행 사진을 공유하기 위해 사진 공유사이트인 Faji를 사용 합니다. 그녀는 faji.com에 로그인하고 비공개로 설정한 두장의 사진을 업로드 합니다.
OAuth에서 쓰이는 용어에 따르면 Jane은 사용자이고 Faji는 서비스 프로바이더입니다. Jane이 업로드한 2장의 사진은 보호된 데이터(Protected Resource)가 되겠죠.
그녀의 몇몇 친구들과 사진을 공유한 다음, Jane은 그녀의 할머니와도 사진을 공유하려 합니다. 그녀는 희귀한 스코트랜드의 병 사진을 다른사람들과 공유하고 싶지는 않습니다. 하지만 할머니는 인터넷에 접속할 수 없기때문에 Jane은 그 사진을 인쇄해서 할머니에게 보내려 합니다. 이를 위해 Jane은 Beppa라는 온라인 인쇄 서비스를 사용하려 합니다.
OAuth에서 쓰이는 용어에 따르면 Beppa는 컨수머입니다. Jane이 사진을 비공개로 해 놓은 이상, Beppa가 그 사진을 인쇄하기 위해 사진을 얻기 위해서는 OAuth인증을 해야 합니다.
Jane은 beppa.com에 방문하고 인쇄 명령을 내립니다. Beppa는 Faji를 포함한 많은 외부의 사진공유 사이트들에 잇는 사진들을 가져올 수 있도록 지원합니다. Jane은 사진이 있는 곳의 서비스를 선택하고 Continue버튼을 누릅니다.
Beppa가 Faji 사진을 가져올 수 있도록 지원하고자 한다면, Beppa 개발자는 Faji의 OAuth인증을 사용하는 API를 사용하기 위하여 Faji로부터 컨수머 키(Consumer Key)와 컨수머 시크릿(Consumer Secret)을 사전에 받아와야 합니다.
Jane이 Continue버튼을 누른 후, 뒷단에서는 Beppa와 Faji간의 중요한 일들이 일어납니다. Beppa는 Faji에게 리퀘스트 토큰(Request Token)을 요청합니다. 이 때, 리퀘스트 토큰(Request Token)은 사용자와는 전혀 상관이 없으며, Beppa가 Faji에 있는 Jane의 비공개 사진에 접근하는 것을 승인하기 위하여 사용될 뿐입니다.
Jane은 Continue버튼을 누르고 화면이 바뀌길 기다립니다.
Beppa가 리퀘스트 토큰(Request Token)을 받으면, Faji의 OAuth 사용자 인증 URL로 방금 받은 리퀘스트 토큰(Request Token)과 함께 리다이렉트 시키고, Jane이 승인을 하면 http://beppa.com/order로 되돌아오게 할 것을 요청합니다.
Jane은 Faji로 리다이렉트되고 사이트에 로그인할 것을 요청받습니다. OAuth는 서비스 프로바이더가 먼저 사용자를 인증하고, 컨수머에게 접근권한을 줄 것인지 승인을 받습니다.
Jane은 브라우저에 있는 URL을 통해 그녀는 지금 Faji사이트에 있다는 것을 알게 되며, 아이디와 비밀번호를 입력합니다.
OAuth는 Jane이 그녀의 아이디와 비밀번호를 Beppa나 다른 사이트들이 공유하지 않게끔 해줍니다. Jane이 그녀의 faji에 대한 비밀정보(아이디,비밀번호)를 beppa.com에 입력하는 과정이 없기 때문이죠.
Faji에서 로그인에 성공하면, Jane은 Beppa에게 Faji에 접근할 수 있는 권한을 부여하기 위한 승인을 하게 됩니다. Faji는 Jane에게 누가 접근요청을 하는지(여기서는 Beppa가 되겠죠) 알려주며 승인을 할 것인지 묻습니다. Jane은 승낙하거나 거절할 수 있습니다.
Jane은 Beppa가 필요한 만큼만 제한적으로 접근할 수 있게 해줍니다. 그녀는 Beppa가 그녀의 사진을 수정하거나 다른 일들을 하는 것을 원하지 않습니다. 또한, Beppa가 Faji에 있는 그녀의 사진을 가져오는데는 1시간이면 충분하다는 것을 알고 있습니다.
Jane이 요청을 승낙하면 Faji는 리퀘스트 토큰(Request Token)을 Jane으로부터 "사용자 승인이 된" 토큰으로 표시합니다. Jane의 브라우저는 리퀘스트 토큰(Request Token)과 함께 보내온 http://beppa.com/order 주소로 리다이렉트 시킵니다. 이는 Beppa가 Jane의 사진을 가져오는 작업을 계속 할 수 있다는 것을 알려주는 것입니다.
Jane은 Beppa가 Faji 계정으로부터 사진을 가져오는 것을 기다립니다.
Jane이 기다리는 동안, Beppa는 인증된 리퀘스트 토큰(Request Toekn)과 액세스 토큰(Access Token)을 교환홥니다. 리퀘스트 토큰(Request Token)은 사용자의 승인을 얻어내기 위해 사용될 뿐이며, 액세스 토큰(Access Token)은 보호된 자원(Protected Resource : 여기에서는 Jane의 사진이 되겠죠)에 접근하기 위해 사용됩니다. 첫 번째 요청에서, Beppa는 리퀘스트 토큰(Request Token)을 액세스 토큰(Access Token)으로 바꾸고, 두 번째로 사진을 요청(여러번 요청이 될 수 있겠죠. 한번은 사진의 리스트를, 다른한번은 각 사진을 가지고 오는 등...)합니다.
Beppa가 작업을 마치면 Jane의 브라우저는 작업을 다 마쳤음을 보여주는 화면으로 바뀝니다.
Beppa는 성공적으로 Jane의 사진을 가져왔습니다. 그녀의 사진을 선택할 수 있도록 썸네일로 보여줍니다.
Jane은 Beppa가 그녀의 아이디와 비밀번호를 모르는데도 불구하고 그녀의 사진을 가져왓다는 것에 놀랍니다. 그녀는 화면에서 시키는데로 인쇄요청을 합니다.
여기까지 사용자 관점에서 본 OAuth 인증과정을 살펴보았습니다. 이제 이러한 인증과정에 맞춘 컨수머 개발을 하기 위해서 OAuth프로토콜 관점에서본 OAuth인증 과정을 살표보시기 바랍니다.(보러가기)