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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server