초보자를 위한 oAuth 가이드 - Workflow
사실은 저를 위한 정리입니다만, 같이 보면 좋을것 같아서 블로그에 올립니다.
OAuth의 흐름에 대하여 실제 예를 들어서 설명해 보고자 한다.
그녀가 집에 돌아왔을때 그녀의 친구들과 휴가 사진을 공유하고 싶어졌다.
그녀는 사진 공유를 위하여 Faji.com 을 사용하고 있어서 비공개 상태로 2장의 사진을 업로드 했다.
OAuth의 개념으로 , 제인은 User 이고, Faji 인 Service Provider 이다. 업로드된 2개의 사진은 Protected Resources 이다.
몇몇의 친구들과 사진을 공유한 그녀는 할머니에게도 사진을 공유하고 싶어졌다.
그렇지만 할머니는 인터넷을 사용하지 않으시기 때문에 온라인 사진인화 서비스를 이용하여 인화후에 우편으로 사진을 보내려고 한다. 온라인 사진 인화 사이트로는 Beppa를 사용하고 있다.
OAuth의 개념으로 Beppa는 Consumer이다. 왜냐하면 제인은 사진을 비공개로 설정해놓았기 때문에 Beppa는 사진인화를 위하여 그 사진들에 대한 access 권한을 얻기 위하여 OAuth를 사용해야 하기 때문이다.
제인은 Beppa.com을 방문하여 사진 주문을 시작하였다. Beppa는 다른 사진 사이트들로부터의 import를 지원하고 있고 제인은 Faji를 선택 하고 계속 버튼을 클릭하였다.
Beppa.com에서 Faji 의 사진을 import 하는 기능을 support 하기 위하여서는 Beppa 개발자 - OAuth개념에서 Consumer Developer - 는 Consumer Key와 Consumer Secret 을 Faji로 부터 받아야만 Faji의 OAuth API를 사용할 수 있다.
제인이 계속 버튼을 클릭한순간 background에서는 중요한 일이 발생한다.
Beppa는 Faji로 request token을 전송한다. 이 Request Token은 사용자별로 생성되는 것은 아니기 때문에 제인의 비공개 사진에 접근하기 위하여서는 그녀(User)의 허락을 얻어야만 한다.
제인이 Faji로 redirect 되면 로그인을 요청받게 된다. OAuth는 Service Provider의 User 인증을 먼저 요청하고 그 후에 Consumer에게 access권한을 요청하기 때문이다.
OAuth는 그녀의 아이디와 패스워드를 Beppa나 다른 사이트와는 공유하지 않도록 해주며, 그녀의 개인적인 정보를 beppa.com에 입력할 필요가 없게 해준다.
Faji에 성공적으로 로그인한 후에 , Consumer인 Beppa에서 접근할 수 있도록 허가 해 줄것을 요청받는다.
Faji는 제인에게 Beppa가 접근할 것을 요청하였다는 것을 알려주고, 제인은 허용하거나 거부할수 있다.
제인은 Beppa가 제안적인 접근을 하려고 한다는 사실을 확인한다. 제인은 Beppa가 그녀의 사진이나 다른것을 변경하도록 허용하는 것을 원하지는 않고 있다. Beppa는 그녀의 사진을 가져오기 위하여 오직 이번 한번만 한시간 동안만 접근할 수 있다는 사실을 인지하게 된다.
제인이 이 요청을 허용하게 되면 Faji는 Request Token을 제인에 의하여 사용자가 허용하였다고 표시해 둔다.
제인의 브라우저는 Beppa로 리다이렉트 되는데 이전 Request Token과 함께 제공되어진 http://beppa.com/order 주소로 리다이렉트 된다.
이제 Beppa는 제인의 사진을 가져올 수 있다는 것을 알게 된다.
제인이 기다리는 동안 Beppa는 허용된 Request Token을 이용하여 Access Token을 받게 된다.
Request Token은 오직 사용자의 허용을 요청할때만 유효하고, 반면 Access Token은 제인의 사진과 같은 제한적인 리소스에 접근할수 있다.
Beppa가 작업을 끝내면 제인의 브라우저는 리로드 되면서 작업은 마무리 된다.
Beppa는 성공적으로 제인의 사진을 가져왔다.
