[翻译]OAuth入门指南 - 2. 协议工作流
通过实际的案例学习OAuth有助于加深理解。规范文档的附录A中包含了一个类似的示例，只不过它聚焦HTTP请求响应的结构。这里对这个典型的OAuth会话应用重新进行演示，并从用户、消费者和服务提供商的角度看待问题。文中提到的网站和人员都是虚构的。不过提到的苏格兰人名是真的。我们的故事是这样开始的…
Jane刚结束她的苏格兰之旅。她花了2周的时间在Islay岛上欣赏美景。当她回到家里，Jane想和朋友们分享一些她在旅行中的照片。Jane使用Faji，一个照片分享网站，来分享旅途中的照片。她登录faji.com的帐号，上传了2张照片并把它们标记为私有的。
在OAuth的术语中，Jane是一个用户，而Faji是服务提供商。Jane上传的2张照片是受保护的资源。
Jane和一些在线的朋友分享了她的照片，之后她还想把照片拿给她的祖母看。她不想和其他人分享她的苏格兰之旅。但是祖母不会上网，因此Jane决定打印一些照片并把这些照片邮寄给她的祖母。Jane选择了Beppa（一个界面友好的在线照片打印服务商）来打印这些照片。
在OAuth的术语中，Beppa是一个消费者。由于Jane把这些照片设为私有资源，Beppa在打印前必须通过OAuth来获取对这些照片的访问权限。
Jane访问beppa.com网站，开始下订单。Beppa支持从很多照片分享网站导入照片，包括Faji。Jane选择照片来源并点击继续按钮。
当Beppa添加对Faji的照片导入支持时，Beppa开发人员（在OAuth中称为Consumer Developer）从Faji获得了一个Consumer Key和一个Consumer Secret，这些信息用来配合Faji的OAuth API使用。
Jane点击继续按钮的时候， Beppa和Faji之间在后台发生了一件重要的事情。Beppa向Faji请求一个Request Token。此时，Request Token是不含用户信息的，之后用户可以授权Beppa使用此信息访问她的私有照片。
Jane点击继续按钮，然后等待她的屏幕发生变化。等待页面加载的过程中，她悠闲地喝了一小口Black Bowmore（一种威士忌）。
当Beppa接收到Request Token，它把Jane重定向到Faji的OAuth用户认证页面，请求中包含了Request Token信息以及在获得用户授权Faji之后返回的页面地址http://beppa.com/order。
Jane已经被重定向到Faji页面，并请求登录网站。OAuth要求服务提供商首先认证用户，然后请求他们将资源授权给消费者。
通过查看地址栏的URL，Jane注意到她被带到了Faji页面，她输入了用户名和密码登录Faji网站。
OAuth允许Jane不公开用户名和密码，无需和Beppa或者其他任何网站分享用户名和密码。Jane也没有在beppa.com输入登录凭证。
成功登录Faji后，Jane被询问是否授权给消费者Beppa。Faji会提示Jane是谁在请求访问权限（本例中是Beppa）以及需要哪些访问权限。Jane可以批准或者拒绝这个请求。
Jane确认Beppa只有有限的访问权限。她不想Beppa修改她的照片或者对它们进行其他操作。她也注意到这是一次性的授权，并且只在接下来的1个小时内有效，这个时间足够Beppa获取她的照片了。
一旦Jane批准了这个请求，Faji就标识这个Request Token已经被Jane授权。Jane的浏览器会被重定向到Beppa的页面http://beppa.com/order，此页面地址之前和Request Token一道作为请求信息传递。这就告诉Beppa可以继续获取Jane的照片了。
Jane等待Beppa显示从Faji帐号中获取的照片。
在Jane等待的时候，Beppa使用认证过的Request Token来换取Access Token。Request Token仅仅用来获取用户的批准，而Access Token可以用来访问受保护的资源（在这个例子中是Jane的照片）。所以第一个请求，Beppa使用Request Token换取了Access Token，第二个请求（可能是多次请求，一个用来获取照片列表，其他的用来获取每张照片的详细信息）用来获取照片。
当Beppa完成的时候，Jane的浏览器会刷新以完成订单。
Beppa成功的获取了Jane的照片。照片以缩略图的形式呈现出来，供Jane挑选出来打印。
Jane对于Beppa不需要她的用户名密码就能获取她的照片的行为印象深刻。她很喜欢这一切，并高兴地完成了打印照片的订单。
====
