thehowofoauth这个挺不错TheHowofOAuth.pptVIP

To let the user give access to their protected data, we leverage three credential sets (a public token, and a shared secret) Our end goal is to get an Access Token into the consumer’s DB, which it will use to sign requests and access the User’s protected data Request tokens are chuck e cheese token Consumer keys don’t really fit into the analogy, but they are used to uniquely identify the consumer, . * After you get your head wrapped around OAuth and are an implementing machine, you’ll only need to know 3 things to integrate OAuth. First, the request token url is used by the consumer to get a new request token to kick start the OAuth process As a consumer, you will redirect users to the Authorization URLs so they can authorize your application to access their data. Flickr “Yes, allow it” page Finally, the access token url is used by the consumer to exchange the request token authorized by the user for a permanent access token Note, the end-user will only ever worry about the authorization url, the other two are used for server to server communications. These three URLS must exist to be an OAuth SP, but what they actually are is up to you. Maximum flexibility for different web frameworks. You need to communicate these URLs to your developers Let’s jump into the meat of it, shall we? As a developer, you’ll only worry about either being a consumer, or being a service provider (or both!) * Let’s first build a consumer. The sample code I’ll be working off of is in Ruby, but there are other libraries at OA, most likely for you fav language as well. It’s worth that some of this is psuedo code, since I won’t be specific about what Web Framework we use. * So, we aren’t quite yet into implementing OAuth in our app. First, we’ll need to get a Consumer key and secret from the Service Provider we are intending to use. The OAuth Core spec doesn’t define how a consumer should get a key and secret from the SP, you’ll have to find out for each service