After reading this article you’ll know how to:
Create an application with a Google sign-on login method
Set up the SSO configurations
Configure the callback page
Build Google callback action flow
Single sign-on (SSO) is an authentication method that allows users to securely log in to different services using a single ID. With SSO, they can access all needed applications without being required to authenticate using different credentials.
Google Account SSO allows existing Gmail and G-Suite users to sign on. When you enable SSO, users are redirected to an external identity provider (IdP) to authenticate. This IdP will be the system of record for authenticated users. You don’t need to synchronize passwords to Cloud Identity or Google Workspace.
This article will kickstart you into setting up your Google SSO configuration for the current-gen version of your Betty Blocks application.
Getting started
Open the application you want to use for setting up a Google SSO login method. Let’s first create a new model for our web users, so that we can use it later as a login model. Go to Data model > Create new model (+). The necessary properties to add are Email and Password, add them to your model.
Create a new page using one of the default page templates - User, account login only. It will save us some time because it has the needed login form for our future settings. While configuring the login form in it, create a new authentication profile (we called it just Google SSO profile) and use our new model (Webuser) as a login model, with Email as a username property and Password as a password property.
Note: Also, it would be useful to have a home page in your application, so that you can choose to redirect your users to it from this configuration. Pick it up here if you already have one.
The authentication profile we’ve just created needs to be adjusted to our future settings. Go to Tools > Authentication profiles > Google SSO profile. Here, select the same values as the ones you see on the screenshot below. Press ‘Save’ when you’re done.
Configuring the login page
To continue our configuration, come back to the login page where we would need to reconfigure it: unlock the wrapper and delete the existing form component(if you use the pre-built configuration like we are using the page template in this example). Then add a new open page component to one of the boxes.
When the open page gets added to our login page, the new configuration window will open and here you have to choose the external page and paste the URL that you need to retrieve from Google’s side.
What to do in order to retrieve the needed URL? Open Using OAuth 2.0 for Web Server Applications in Google’s documentation. Here, in the Create authorization credentials section, you will find some steps on how to get the credentials we need from Google.
This is what the URL you need to pass to the open page button looks like:
First, you need to configure it by replacing <CLIENT_ID> with the client ID that you can find in the configuration in Google credentials.
Then replace <REDIRECT_URI> with the URL of your Betty Blocks app (e.g. https://google-sso-example.betty.app/) with the path of the page you want the return callback to be handled (in our example, google-callback).
Eventually, the URL should contain a piece similar to the one you see below. We will copy it to the Authorised redirect URLs for use with requests from a web server:
If everything is working so far, you’ll be able to reach the signing-in page.
Callback page
Once you’ve settled the authorization from Google’s side, it’s time to do so from Betty’s side. We are going to create a separate page with a form and hidden input to post the code that Google sends to an action (created behind the form component). This action will handle retrieving the user information and signing them into their Betty Blocks account. Basically, instead of having a classic login form with an email address (login) and password, we retrieve the code from Google and post that in a form that is automatically submitted.
Let’s start by creating a Google callback page:
Add a form component to the page. In its configuration turn off the Model-based form toggle and come up with a name for your action that will be added along with this form component (for instance, ‘Google Callback’)
Switch to the data tab at the top of the page builder menu and add a new text variable ‘code’. It is used to retrieve the authentication code from Google (which is being traded for the actual access token).
Come back to the components tab and add a hidden input component to the page and type in the name for the action input variable (e.g. ‘code’)
Select the newly added hidden input component and add our previously created text variable ‘code’ to it.
You can delete unnecessary components (the button and text field). Now we will make sure the user gets to the right points while interacting with the SSO:
Select the form component and open the interactions tab
Then create a new interaction to be sure when the form is rendered, that is user’s credentials are submitted. The action will handle the retrieval of user info.
onRender - Submit - Form
Reconfigure the ‘onActionSuccess’ interaction to get the following:
onActionSuccess - Login - (Redirect to) ‘Home’ page
Now, if the form is sent, the login will succeed.
Lastly, you can edit the permissions of an action that stands behind our form - make it public.
Building an action flow
Within this part of the configuration, we will set up the action flow of the Google Callback action to make sure the access tokens are processed in the right way. To complete this, we need a bunch of action steps that come with one of the blocks from the block store - OpenId - Connect.
Find this one in the block store and install it to your application. Open the Google Callback action and follow the instructions, we will add steps one by one:
1. getAccessAndIdToken - fill in its options with the data you retrieved from the Google authorization credentials: token endpoint, client ID, client secret, etc. Use our ‘code’ variable as the authorization code. Press Save when you’re done with this one.
2. Decode an OpenID connect ID token - select the idToken variable from the previous step to be decoded and name the result of decoding as decodedToken.
3. Get User Data from ID Token - this step is responsible for fetching the user data from the ID token, we’ll put them in variables: select the decodedToken (the result of the previous step) and come up with names for the rest of the variables. Within this step, we get the user data - email, username, etc.
Now we will add a condition step to check if the user already exists in the system:
Go to the Variables tab and click on Add.
Then create a new record variable (e.g. existingUser),
Select Webuser model
Filter on Email equals username
Press Save.
Open the Paths tab
Set the filter rule: existingUser exists
Change paths names to something like in the example below
Press Save.
4. Next, drop the create record step to the else (New User) path, so that whenever a user doesn’t have his record yet, it gets created.
In the options tab:
Select the Webuser model
Email property + username value
Fill in the name for the result variable (e.g. newWebuser)
Go to the variables tab and create a new collection variable (e.g. roles) and select the Role model. Click Save.
Each user at Betty Blocks needs to have a role - we assign all the roles at the same time. Come back to the options tab and add a new value:
Note: You can differentiate the roles by assigning them specifically. It’s done by filtering.
5. Take the authenticate user step and drag it to the borrow of the actin flow.
Open this step and go to the variables tab:
Add a new record variable (e.g. webuser)
Select the Webuser model
Filter on Email equals username.
Come back to the options tab:
Select the Google SSO authentication profile
Choose webuser.Id as record Id
Result as jwtToken
6. Open the finish step and select jwtToken as an output variable.
Final check
Before checking if everything is done right, make sure you’ve set Google SSO as an authentication profile on all the pages you need your users to reach.
Compile the Login page to see if your setup for Google SSO is working.
Note: For companies using their own SSO login method the steps might be a little different. Reach out to our support team if you have any extra questions.