OAUTH 2 Login with MultiValue BASIC — Part 3
In the last article, part 2, we talked about setup and subroutines needed to send an OAUTH 2 request to a web service. This time, we'll talk about the request process used to get a valid oAuth bearer token which needs to be included in those requests.
The first thing that you have to decide is how you are going to login and authenticate with the web service. Sometimes the web service will dictate this and sometimes you can choose. See part 1 of the article for more information about the different ways it might work.
Attached to this article (on the International Spectrum Website) there is a program called IS.OAUTH 2.REQUEST which is an example of all that steps we're going to talk about here.
Initial oAuth Request
Much of the interaction with OAUTH 2 login services is self-contained, but there are times when a user is required to do something more complicated. In order minimize the complexity, the OAUTH 2 specification supplies a refresh token.
To get your refresh token for the first time, your program will need to make the initial request the long way. You need to create the HTTP post data to send to the request URL. Using the data found in the OAUTH.CONTROL.SUPT file for the Google+ oAuth, the URL would look like this, as seen in line three of the program:
https://accounts.google.com/o/oauth2/auth?scope=email profile
Once you have the URL, you have to add the additional data to authenticate with it.
Grant Type: Native or Code
Native or Code grant types are the most common and include some additional information, which can be found in the OAUTH.CONTROL record. You will need to pull the consumer key from line one, and the Redirect URL found in line twenty-five. If you want more information about this, look at the Redirect URL section.
Create the HTTP post data with this information (see [Figure 1]) and then make the request. It will then return back JSON-formatted information which you can send to the Get Access Token process.
URL = '
https://accounts.google.com/o/oauth2/auth'
POST.DATA<-1> = 'scope' :VM: 'email profile'
POST.DATA<-1> = 'response_type' :VM: 'code'
POST.DATA<-1> = 'client_id' :VM: ITEM.OAUTH <1>
POST.DATA<-1> = 'redirect_uri' :VM: ITEM.OAUTH <25>
CALL IS.HTTPCLIENT('POST',URL,'',POST.DATA,RESP.HTTP.STATUS,'',RESP.DATA,HTTP.ERROR)
Fig. 1
Redirect URLs
The redirect URL is an odd piece of information. Normally this would be a URL on YOUR web server that the oAuth service can callback to and give you the oAuth bearer information. This allows additional security, but it also requires you to have a public webserver that can pass information back into your database.
Don't fear, that is not always required. The writers of the OAUTH 2 specification took into account that a public webserver may not be available to receive the callback, so you are allowed to supply a unique identifier that tells the authorizing web service that the user is willing to go through an additional effort to get the information.
This code is "oob" or "urn:ietf:wg:oauth:2.0:oob". Be aware that not all OAUTH 2 login services support this.
What does this mean? The authorizing web service will return a URL that the user can place into a web browser, which will take them to the additional login information that they will need to answer, after which the authorizing web service will provide a PIN number that can be used for future request.
The IS.OAUTH2.REQUEST program places the PIN Number Request URL into line eighteen and requires the user to place the PIN returned from that request into line seventeen.
Refresh Tokens
Refresh tokens allow the auto-refresh of bearer tokens without going through the whole login process each time. This allows your routines to update the OAUTH 2 tokens easily as long as the refresh token has not expired. If the refresh token has expired, then you will have to repeat the whole login process described in the section above.
This really only becomes an issue if you don't call the oAuth service on a regular basis. Most authorizing web services will keep you logged in, and your bearer token active, as long as you are using their services on a regular basis.
Putting it All Together
I have included the source code for an enhanced version of the IS.HTTPCLIENT routines to support OAUTH 2. This routine can be found at:
http://www.intl-spectrum.com/ resource/category/190/httpclient.aspx
The BASIC program call structure is the same as the IS.HTTPCLIENT subroutine, but it adds an extra argument for the OAUTH.CONTROL record id. This allows the IS.OAUTH.HTTPCLIENT to control and maintain the bearer token and the refresh tokens [figure 2].
SUBROUTINE IS.OAUTH.HTTPCLIENT(OAUTH.ID,HTTP.METHOD,URL,HEADER.DATA,POST.DATA,RESP.HTTP.STATUS,RESP.HEADER.DATA,RESP.DATA,HTTP.ERROR)
Fig. 2
When a new bearer token is required, then the subroutine will call IS.OAUTH2.REQUEST to do all the handshaking, as we discussed in the previous articles.
If you look closely at the code of IS.OAUTH.HTTPCLIENT, you will also see support for OAUTH 1.0A. OAUTH 1.0A was originally created by Twitter, and is still used by Twitter, but it is more complex, and not something I'll get into here.
See [Figure 3] for a full example using IS.OAUTH.HTTPCLIENT and Google's API. The output can be found in [Figure 4].
001 OAUTH.ID = "GOOGLE.NATIVE"
002 *
003 URL =
https://www.googleapis.com/plus/v1/people/me
004 CALL IS.OAUTH.HTTPCLIENT(OAUTH.ID,"GET",URL,"","",RESP.HTTP.STATUS,RESP. .DATA,OAUTH.ERROR)
005 CRT RESP.DATA
Fig. 3
You'll notice that [Figure 4] is JSON, as most web services these days require. If you are looking for information on JSON parsers that can be used within your MultiValue databases, then go to the following URL:
{
"kind": "plus#person",
"etag": "\"4OZ_Kt6ujOh1jaML_U6RM6APqoE/fwy9zqRNk6f6v6VM0sZCmoLvPXY\"",
"gender": "male",
"emails": [
{
"value": "Nathan@intl-spectrum.com",
"type": "account"
}
],
"urls": [
{
"value": "
http://www.intl-spectrum.com/experts/experts.aspx?a=243655"
,
"type": "contributor",
"label": "International Spectrum Magazine"
}
],
"objectType": "person",
"id": "112065600037302709921",
"displayName": "Nathan Rector", "name": {
…
}
Fig. 4
http://www.intl-spectrum.com/resource/category/69/JSON.aspx
Conclusion
You should now have all you need to make oAuth work within a MultiValue database. This can be used in many different places to enhance your application and interact with Office 365, Google Drive, Salesforce, and others.
