[Translation] oauth Getting Started Guide-2. Protocol Workflow

Author: Eran hammer-Lahav

Translator: sanshenshi

Original article: Beginner's Guide to oauth-Part II: Protocol Workflow

Disclaimer: This Chinese translation is independently completed by sanshenshi. the blog is the first to be published in the blog Park. Please indicate the source for reprinting.

 

Learning oauth through actual cases helps deepen understanding. Appendix A of the normative document contains a similar example, except that it focuses on the structure of the HTTP request response. Here we will re-demonstrate this typical oauth session application and look at the problem from the perspective of users, consumers, and service providers. All websites and personnel mentioned in this article are fictitious. However, the names of Scotland are true. This is how our story begins...

Jane just finished her trip to Scotland. She spent two weeks enjoying the beautiful scenery on Islay. When she returned home, Jane wanted to share some photos of her travels with her friends. Jane uses Faji, a photo sharing website, to share photos on her journey. She logged on to faji.com, uploaded two photos, and marked them as private.

In oauth terminology, Jane is a user, and Faji is a service provider. The two Photos Uploaded By Jane are protected resources.

Jane shared her photos with some online friends and she wanted to show them to her grandmother. She doesn't want to share her trip to Scotland with others. But her grandmother does not access the Internet, so Jane decided to print some photos and mail them to her grandmother. Jane chose beppa (an interactive online photo printing service provider) to print these photos.

In oauth terminology, beppa is a consumer. Because Jane sets these photos as private resources, beppa must use oauth to obtain access to these photos before printing.

Jane visits the beppa.com website and starts placing orders. Beppa supports importing photos from many photo sharing websites, including Faji. Jane select the photo source and click "continue.

When beppa adds support for Faji photo import, beppa developers (called consumer developer in oauth) Obtain a consumer key and a consumer secret from Faji, this information is used in combination with the oauth API of Faji.

When Jane clicked the continue button, an important thing happened between beppa and Faji in the background. Beppa requests a request token from Faji. In this case, the request token does not contain user information, and then the user can authorize beppa to use this information to access her private photo.

Click "continue" and wait for her screen to change. While waiting for page loading, she drank black bowmore leisurely ).

When beppa receives the request token, It redirects Jane to the oauth user authentication page of Faji. The request contains the request token information and the page address returned after obtaining the user authorization Faji: http://beppa.com/order.

Jane has been redirected to the Faji page and requested to log on to the website. Oauth requires the service provider to first authenticate the user and then request them to authorize the resource to the consumer.

By viewing the URL in the address bar, Jane noticed that she was taken to the Faji page, and she entered the user name and password to log on to the Faji website.

Oauth allows Jane not to disclose the user name and password, and does not need to share the user name and password with beppa or any other website. Jane does not enter the logon credential in beppa.com.

After successfully logging on to Faji, Jane is asked whether to authorize the consumer beppa. Faji will prompt Jane who is requesting access permissions (beppa in this example) and what access permissions are required. Jane can approve or reject this request.

Jane confirms that beppa has limited access permissions. She doesn't want beppa to modify her photos or perform other operations on them. She also noticed that this was a one-time authorization and only valid for the next hour. This time is enough for beppa to get her photos.

Once Jane approves the request, Faji identifies that the request token has been authorized by Jane. Jane's browser will be redirected to the beppa page at http://beppa.com/order. the front of this page and the request token will be used as request information for transmission. This tells beppa to continue to get Jane's photo.

Jane waits for beppa to display the photos obtained from the Faji account.

While Jane is waiting, beppa uses the authenticated request token in exchange for the access token. The request token is only used to obtain the user's approval, and the access token can be used to access protected resources (in this example, the photo of Jane ). Therefore, in the first request, beppa used the request token in exchange for the access token and the second request (which may be multiple requests, one request for obtaining the photo list and the other for obtaining the details of each photo) used to obtain photos.

When beppa is complete, Jane's browser refreshes to complete the order.

Beppa successfully obtained the photo of Jane. The photo is displayed as a thumbnail for Jane to select and print.

Jane was impressed with beppa's behavior of getting her photos without her username and password. She liked everything and was happy to finish the order for printing photos.

 

====

Html pdf version