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.

Google access token

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.

To get an idea of how Google designed this system, it's best to read up on Google's OAuth 2.0 documentation here: Google OAuth 2.0 and OAuth 2.0 for Mobile & Desktop Apps

As they explain in the article, using their authentication flow consists of these 4 steps:

Obtain OAuth 2.0 credentials from the Google API Console.
Obtain an access token from the Google Authorization Server.
Send the access token to an API.
Refresh the access token, if necessary.

Obtain OAuth 2.0 credentials from the Google API Console.

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 the 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.

Obtain an access token from the Google Authorization Server.

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:

access_token: Text (single line)
access_token_expires_in: Number
access_token_issued_at: Date time
code: Text (single line)
refresh_token: Text (single line)
access_token_expires_at: Date time expression
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.

The 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:

https://accounts.google.com/o/oauth2/auth?approval_prompt=force&scope=<googlescopes>&client_id=<clientid>&redirect_uri=<redirecturi>&response_type=code&access_type=offline&state=<userid>

Each value between the < > marks are to be replaced with the following values.

googlescopes: All the scopes we want the user to have access to. A complete list of available scopes can be found here: Google API Scopes
clientid: The client ID you acquired in the first part.
redirecturi: https://<yourappname>.bettywebblocks.com/google/callback The redirect URI should match the Authorized redirect URI you entered when creating a Client ID.
userid: In this case the record ID of the user we want the access token to be related to. Google will send this as an additional parameter in the callback so we can recognize the user by this ID.

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 is 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!

Setting up our Betty Blocks application.

With the configurations in Google and a data model 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.

Google OAuth 2.0 Webservice

Go to Webservices in your Betty Blocks application and create a new Webservice to request Google's OAuth flow.

Name: Google OAuth 2.0
Protocol: HTTPS
Host: "www.googleapis.com"
Authentication Type: None
Request Content-Type: JSON
Response Content-Type: JSON

Click Save and create a Webservice endpoint.

Name: Get Access Token
Http method: POST
Path: "/oauth2/v4/token"
Request Content-Type: [inherit]
Response Content-Type: [inherit]
Response code: 2..

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.

client_id: (is input variable)
client_secret: (is input variable)
code: (is input variable)
grant_type: authorization_code
redirect_uri: (is input variable)

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:

expires_in: Number
access_token: Text
refresh_token : Text

Google OAuth 2.0 Callback page

Now we're going to create an endpoint in our Betty Blocks application that resembles the callback endpoint entered in Google. Go to Endpoints and create a new Endpoint.

Path: google/callback
Request Method: GET

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.

code: Text
state: Number

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 back office 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.

Refresh the access token, if necessary.

This process is similar to what has been discussed already but doesn't require the user to actually log in 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
Path: "/oauth2/v4/token"
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.

client_id: (is input variable)
client_secret: (is input variable)
refresh_token: (is input variable)
grant_type: authorization_code

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 is successfully executed. For more info, take a look at Google's documentation about refreshing tokens here: Refreshing an access token