A Primer to the OAuth Protocol
The term nonce means “number used once” and is a unique and usually random string that is meant to identify each signed request uniquely.
The Service Provider checks the signature of the request and replies with an unauthorized request token:
The Consumer redirects Jane's browser to the Service Provider User Authorization URL:
http://photosharingexample.com/authorize?oauth_token= ↪hh5s93j4hdidpola&oauth_callback= ↪http%3A%2F%2Fphotoprintingexample.com%2Frequest_token_ready
If Jane is logged in to photosharingexample.com, this page will ask her whether she authorizes photoprintingexample.com to have access to her account. If Jane authorizes the request, her browser will be redirected back to http://photoprintingexample.com/request_token_ready?oauth_token=hh5s93j4hdidpola, telling the consumer that the request token has been authorized. The Consumer then will exchange the Request Token for an Access Token using the following address:
https://photosharingexample.com/access_token? ↪oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token= ↪hh5s93j4hdidpola&oauth_signature_method=PLAINTEXT& ↪oauth_signature=kd94hf93k423kf44%26hdhd0244k9j7ao03& ↪oauth_timestamp=1191242092&oauth_nonce= ↪dji430splmx33448&oauth_version=1.0
which will return the Access Token in the response:
This exchange will happen only the first time Jane tries to access her photosharingexample.com photos from photoprintingexample.com. Any time afterward, only the following will happen.
Now, the Consumer is equipped properly to access Jane's photos. First, the Consumer needs to generate the request signature. The initial step is to create the Signature Base String. This is a combination of the following elements:
oauth_consumer_key: dpf43f3p2l4k3l03 oauth_token: nnch734d00sl2jdk oauth_signature_method: HMAC-SHA1 oauth_timestamp: 1191242096 oauth_nonce: kllo9940pd9333jh oauth_version: 1.0 file: family.jpg size: original
Ultimately, you end up with the string:
GET&http%3A%2F%2Fphotosharingexample.com%2Fphotos& ↪file%3Dfamily.jpg%26oauth_consumer_key% ↪3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh% ↪26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp% ↪3D1191242096%26oauth_token%3Dnnch734d00sl2jdk% ↪26oauth_version%3D1.0%26size%3Doriginal"
If your request is being transmitted through SSL, the request can be in plain text. However, a vast majority of Web sites do not use SSL, so the signature string must be encoded.
Traditionally, the HTTP protocol uses an authentication method it calls “Basic” in which users provide their user names and passwords in order to gain access to the protected resource. The major flaw in that procedure is that those credentials are passed in plain text, clear for any people listening to read and store as they wish. In order to protect users' credentials, OAuth uses digital signatures instead of sending credentials with each request.
This digital signature is used to verify that the request being made is legitimate and hasn't been tampered with. A hashing algorithm is used to make that work. In order to allow the recipient to verify that the request came from the claimed sender, the hash algorithm is combined with a shared secret. If both sides agree on a secret known only to both parties, they can add it to the content being hashed. This can be done by simply appending the secret to the content, or by using a more sophisticated algorithm with a built-in mechanism for secrets, such as HMAC.
OAuth defines three signature methods used to sign and verify requests: PLAINTEXT, HMAC-SHA1 and RSA-SHA1.
The process of taking data (of any size) and condensing it to a much smaller value (digest) in a fully reproducible (one-way) manner. Using the same hash algorithm on the same data always will produce the same smaller value.
For this example, let's say the Service Provider allows HMAC-SHA1 signatures. Thus, the encoded signature string becomes:
All together, the Consumer request for the photo is:
http://photosharingexample.com/photos?file=vacation.jpg&size= ↪original&oauth_consumer_key=dpf43f3p2l4k3l03& ↪oauth_token=nnch734d00sl2jdk&oauth_signature_method= ↪HMAC-SHA1&oauth_signature=tR3%2BTy81lMeYAr%2FFid0kMTYa% ↪2FWM%3D&oauth_timestamp=1191242096&oauth_nonce= ↪kllo9940pd9333jh&oauth_version=1.0
The Service Provider performs the same work flow to calculate the signature of the request that the Consumer performs. It then compares its calculated signature to the provided signature. If the two match, the recipient can be confident that the request has not been modified in transit. The Service Provider then responds with the requested pictures.
This process can be daunting to deal with programmatically. There are a number of libraries written for both the OAuth server and client for quite a few programming languages.
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
|CodeLathe's Tonido Personal Cloud||Apr 19, 2017|
|Wrapping Up the Mars Lander||Apr 18, 2017|
|MultiTaction's MT Canvus-Connect||Apr 17, 2017|
|Android Candy: Facebook Everything?!?!||Apr 14, 2017|
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Gordon H. Williams' Making Things Smart (Maker Media, Inc.)
- Non-Linux FOSS: Control Web-Based Music!
- IGEL Universal Desktop Converter
- Server Technology's HDOT Alt-Phase Switched POPS PDU