OAUTH 2 Login with MultiValue BASIC Overview
Many web services are starting to require developers to use the OAUTH 2 authentication flow in order to access their web APIs. While this makes working with them a little more difficult, it isn't as bad as some of the documentation makes it out to be.
If you are wondering why companies are doing this, it's pretty simple. Companies like Google, Facebook, Linkedin, Salesforce, and Microsoft have all spearheaded the use of OAUTH 2, causing many other companies to follow close behind.
OAUTH 2 replaces the original OAUTH 1 URL signature process. This is good since OAUTH 1 ended up being a more complicated signature to implement. Some companies, such as Twitter, still use OAUTH 1, but even they have been slowly moving over to the new OAUTH 2 standards.
OAUTH 2 requires developers to include additional information with every web service call to verify that the person making the request is truly who they say they are. This additional information allows the API to determine if the person and/or device that is issuing the call is allowed to do so.
Since OAUTH 2 protocols can distinguish the device in addition to the user, the API can de-authorize a device without de-authorizing the user. As you can see, this has many security advantages.
Login Flows
There are several login flows available with OAUTH 2. This multiplicity is one of the reasons the standard seems so complicated. Another reason is that most of the documentation covers access via websites and mobile devices, which introduces much of the confusion.
All login flows require that the API provides a Consumer Key and a Consumer Secret . These values must be stored within your application and are used to identify the process or device. These keys are usually assigned after you fill out an application to use the web service.
Once you have the Consumer Key and Consumer Secret , you need to find out which login flow the web service is requiring you to use.
These are the three most common login flows:
Password - Resource Owner Password
This login flow is not as secure as the next login flow, but it is the easiest to implement. You provide the Consumer Key and Consumer Secret with a username and password in order to get an access token to use later.
Native - Desktop/Mobile Device Authentication
This login flow requires you to have access to a webserver. During the login process you must include a URL, telling the API where to send the access token. This means there is no user interaction or data entry, but it does require your LOB application to have its own web service available to receive the access token.
As always, there is an exception to this. Some web services allow you to supply a special callback code called an oob. This tells the web service to redirect to a page that includes a PIN number. A user must enter this PIN number.
A second authentication is done using the PIN number to verify that everything is okay. This requires that API developers provide this functionality, so sometimes you see it and sometimes you don't.
Limited - Limited User Access
This login flow allows the authentication process to happen without a callback URL found in the "native" login flow. The application uses a "polling" function to request the access token.
For LOB applications, this would be the next easiest to implement. The only problem is that the developers of the APIs must allow this type of login flow, and most do not.
Access Tokens
The whole point of the OAUTH 2 process is to issue a temporary access token to a device/application combination. This access token can then be de-authorized by the API at any time, or the API can force the device or application to re-authenticate after a period of time.
Along with the access token, the API usually provides an expire-in value ; usually provided as the number of seconds for which the token will be accepted. To figure the exact date and time when the token will expire, your application needs to record the date and time when it received the information. Otherwise it can't check to see if the current date and time are larger than the expire-in value.
Most APIs include a refresh token as well. Refresh tokens allow you to speed up the re-authentication process. There is a limited amount of time during which a refresh token is valid. This will vary from API to API, so it is important to be aware of this, especially if the API is not used often. If the refresh token has expired, you will have go through the complete login flow from the beginning without the benefit of the refresh token.
Once you have the access token, it will need to be added to every request to the API from that point forward.
URL MetaData
Before issuing the request to the API, you must add a new header field to the URL information. This field is an 'authentication' header, and looks something like this:
Authorization: bearer aopi991/all93k1jf7
This is the information that the API will use to validate that your application is allowed to access this specific service.
Next…
My next article will talk about the control record storage and BASIC code needed to comply with OAUTH 2 authentication.
Nathan Rector, President of International Spectrum, has been in the MultiValue marketplace as a consultant, author, and presenter since 1992. As a consultant, Nathan specialized in integrating MultiValue applications with other devices and non-MultiValue data, structures, and applications into existing MultiValue databases. During that time, Nathan worked with PDA, Mobile Device, Handheld scanners, POS, and other manufacturing and distribution interfaces.
In 2006, Nathan purchased International Spectrum Magazine and Conference and has been working with the MultiValue Community to expand its reach into current technologies and markets. During this time he has been providing mentorship training to people converting Console Applications (Green Screen/Text Driven) to GUI (Graphical User Interfaces), Mobile, and Web. He has also been working with new developers to the MultiValue Marketplace to train them in how MultiValue works and acts, as well as how it differs from the traditional Relational Database Model (SQL).
View more articles