Last updated: 27-08-2020
Google offers all kinds of services, enabling you to get the most out of your business. Some of those services make a great combination with Betty Blocks. By integrating with them through their REST API you can give your Betty Blocks application a functional boost.
To determine which Google account you're performing each request with and if you're authorized, you must request an access token. This access token is a centralized way to authenticate each request.
All Google requests, no matter which service, work through this system. This means you only have to implement this integration once in your application and can include it in each workflow you're using Google requests. Whether it's Google Maps, Google Drive or any of the others, you're all set.
As they explain in the article, using their authentication flow consists of these 4 steps:
In this example, we have a Betty Blocks application with the name Google OAuth Showcase. The base URL is `google-oauth.bettyblocks.com`.
First you need to create a project in Google APIs and register your Betty Blocks application to enable API services. To do this, go to the Credentials section. Create new credentials and choose `OAuth client ID`.
You may receive the following warning.
If this is the case, click the `Configure consent screen` and enter a name for your app. Also, enter `bettyblocks.com` and `bettywebblocks.com` as authorized domains.
After saving, you will be redirected to the initial screen for creating a client ID. Choose `Web application` as Application type and name it the same as we named our application. At last, enter the URI you want the user to be redirected to after authenticating. In our example, `https://google-oauth.bettywebblocks.com/google/callback`.
Note: Make sure the authorized redirect URI is the URI of the web endpoint you want the OAuth Access token to be posted back to.
Click `Create` and Google generates a client ID and client secret which we will need in the further process, so copy them so you have them ready! You can always find them again by opening the OAuth 2.0 client IDs in their dashboard.
Before we can continue on to performing requests, we must set up a way to store the acquired access tokens in. Create a model called `GoogleOauthToken` and add the following properties:
var:record.access_token_expires_in != nil & var:record.access_token_issued_at != nil ? var:record.access_token_issued_at + seconds(var:record.access_token_expires_in) : nil
Add a relation to the user model or any model you want to relate the access token to so you can have a per-user access token in the future. In this case, we are going to use the default User model to do this so a User has many GoogleOauthTokens.
Next step is to create a URI for users to initiate the actual OAuth user consent flow.
The URI should be built up as follows:
Each value between the `< >` marks are to be replaced with the following values.
Create this URI and try to visit it in a web browser. The Google OAuth 2.0 flow should be started correctly, prompting you to log in and after allowing access you should be redirected to the callback URI entered in Google. In the background, an access token among other values are generated, which can be used in our further requests.
Now it's time to create a webservice and web page in our Betty Blocks application for this callback to store the access token in!
With the configurations in Google and a datamodel for storage in place, it's time to create webservices and web pages in our Betty Blocks application that are performing the requests and saving the received values.
Go to Webservices in your Betty Blocks application and create a new Webservice to request Google's OAuth flow.
Click `Save` and create a Webservice endpoint.
Also, create additional Query variables to use in our requests. The variables are related to the values used earlier in our URI for testing the user consent flow.
At last, create a new Custom Model on the Webservice endpoint. This Custom model will contain the received response, making it easier to process. Add the following attributes:
Now we're going to create an endpoint in our Betty Blocks application which resembles the callback endpoint entered in Google. Go to Endpoints and create a new Endpoint.
Click `Finish` and see how the page is created. If you entered the path correctly, it should be identical to the Authorized redirect URI entered in Google.
Add 2 Input variables to the endpoint. These input variables will receive values from Google after authentication.
The `code` variable is used to retrieve the authentication code from Google (which is being traded for the actual access token) and the `state` variable is used for the User ID (to connect the access token to the user in the Betty Blocks application).
Add an action on the endpoint to retrieve the access token based on the code sent by Google. Make sure to enable Debug action and events and Log execution of action to see exactly what happens when testing.
Create a GoogleOauthToken record and assign the input variable `code` to its corresponding property and an object variable based on the `state` variable to connect the user.
Then add a Http request event in which we exchange the code for our access token.
Select the input variable `code` in its corresponding Query variable. As `redirect_uri`, enter the Authorized URI configured in Google.
Specify the response as `access_token_response`.
At last, update the created record with the attributes from the response.
Also create a Date time expression variable containing `now` and assign it to the Access token issued at property. This will set a timestamp to the property, so we can calculate when the token will expire.
Now visit the google OAuth URI again and finish the flow. You can easily add a grid in your backoffice application for the GoogleOauthToken model to see if the flow actually works. If you did everything correct, a new record will appear with all the properties filled.
In this construction, each user only needs 1 Access token. The token can be collected as an Object variable for actually performing the Google API request and selecting the access_token property. A token is valid for only 3600 seconds (1 hour) after being issued. When the user has a token, but said token isn't valid anymore, the token can be refreshed.
This process is similar to what has been discussed already, but doesn't require the user to actually login and accept the flow.
If your access token is expired, you can use the refresh token to acquire a new access token first before you call the webservice endpoint.
Create another Webservice endpoint in the Google OAuth 2.0 Webservice.
Name: Refresh Access Token
Http method: POST
Request Content-Type: [inherit]
Response Content-Type: [inherit]
Response code: 2..
Also, create additional Query variables to use in our requests. The variables are slightly different than our previous webservice endpoint.
Same as before, when used in your action(s), enter the `client_id` and `client_secret` in their corresponding Query variables. The value in `grant_type` is already set, but in `refresh_token` you must assign the refresh_token property from the Object variable with the user's access token. Update the token record with the new values, same as before and retry the initial flow. If everything went according to plan, the access token is valid this time and the request successfully executed. For more info, take a look at Google's documentation about refreshing tokens here: Refreshing an access token.