OAuth 공식 사이트 예제 :
http://hueniverse.com/oauth/guide/workflow
http://oauth.net/core/1.0/#anchor25
http://tools.ietf.org/html/rfc5849#section-1.2
위 내용을 번역해 놓은 블로그 :
http://dev.springnote.com/pages/1079410
http://dev.springnote.com/pages/1083108 이게 제일 명확한듯!!
결국 temporary credential = request token 인듯..
좋은 파일 하나 찾아서 또 첨부!!
이건 내가 이해할라고 적어본 내용...
1. When Beppa added support for Faji photo import, a Beppa developer known in OAuth as a client developer obtained a set of client credentials (client identifier and secret) from Faji to be used with Faji’s OAuth-enabled API.
After Jane clicks Continue, something important happens in the background between Beppa and Faji Beppa requests from Faji a set of temporary credentials. At this point, the temporary credentials are not resource-owner-specific, and can be used by Beppa to gain resource owner approval from Jane to access her private photos.
2. When Beppa receives the temporary credentials, it redirects Jane to the Faji OAuth User Authorization URL with the temporary credentials and asks Faji to redirect Jane back once approval has been granted to http://beppa.com/order.
임시 credential 과 함께 (요청하는 놈이 누군지 알아야 되니까) Faji 로그인 페이지로 리다이렉트 시킨 후, 로그인 성공하면 beppa쪽으로 redirect 시켜달라고 요청. 그래서 redirect url도 같이 넘겨주는구나...
Jane has been redirected to Faji and is requested to sign into the site. OAuth requires that servers first authenticate the resource owner, and then ask them to grant access to the client.
누군지 먼저 묻고, 그다음에 client의 access 허용할것인지 물어봄.
OAuth allows Jane to keep her username and password private and not share them with Beppa or any other site. At no time does Jane enters her credentials into beppa.com.
로그인을 faji쪽에 하게 되므로 faji를 포함한 어디에도 로그인 정보를 입력하지 않음. 리소스가 있는 곳에만 인증하면 되는거네...
3. After successfully logging into Faji, Jane is asked to grant access to Beppa, the client. Faji informs Jane of who is requesting access (in this case Beppa) and the type of access being granted. Jane can approve or deny access.
로그인 성공 후 권한을 줄지 말지 결정
4. Once Jane approves the request, Faji marks the temporary credentials as resource-owner-authorized by Jane. Jane’s browser is redirected back to Beppa, to the URL previously provided http://beppa.com/order together with the temporary credentials identifier. This allows Beppa to know it can now continue to fetch Jane’s photos.
기존에 전달한 credential에 마킹을 하는군. beppa.com/order로 리다이렉션 하게 되고, 이 페이지는 인증 성공을 전제로 하기 때문에 사진을 가져오는 코드가 들어있을 듯. 사진 가져올 때도 beppa <-> faji간 인증을 해야겠지?
5. While Jane waits, Beppa uses the authorized Request Token and exchanges it for an Access Token. Request Tokens are only good for obtaining User approval, while Access Tokens are used to access Protected Resources, in this case Jane’s photos. In the first request, Beppa exchanges the Request Token for an Access Token and in the second (can be multiple requests, one for a list of photos, and a few more to get each photo) request gets the photos.
첫번째 단계에서 Request Token을 exchange 한다고 되어 있으므로 두번째 그림이 맞는거 같은데 현재 OAuth 소개 페이지에는 첫번째 그림으로 되어 있네... 두번째 그림은 옛날 페이지에서 퍼온거...
6. When Beppa is done, Jane’s browser refreshes to complete the order. Beppa successfully fetched Jane’s photo. They are presented as thumbnails for her to pick and place her order. 끝~
'개발 > Server Side' 카테고리의 다른 글
ubuntu natty(11.04)에서 apt-get으로 sun JDK 설치 (0) | 2012.02.24 |
---|---|
bash prompt 설정 예제 (0) | 2012.01.25 |
프로세스별 네트워크 사용량 측정 - nethogs (0) | 2011.11.17 |
일정 시간 이상 경과한 로그 지우는 스크립트 (0) | 2011.11.07 |
swap 영역 할당하기 (0) | 2011.10.04 |