Using OAuth SSO with Velo

Single Sign On (SSO) is a great way to make life easier for your site visitors and encourage them to register as a user on your site. Visitors can log in to your site using their Google, Facebook, or other accounts, or using their work account.

This article will look at how to implement OAuth - Open Authentication protocol, which is used by many service providers including Google, Facebook and Twitter. To learn about implementing SSO with SAML, see Using SAML SSO with Velo.

OAuth Flow

An authenticated user session is a session in which the identity of the user has been verified to the server, in the case of OAuth, by a 3rd-party.

The diagram below shows the flows involved in establishing an authenticated user session on a Wix site using Google as an OAuth identity provider. 

The flows are as follows:

  1. The user clicks Sign in with google.
  2. The Wix site requests an authorization URL.
  3. The browser is forwarded to the OAuth provider using the authorization URL, and the user signs in.
  4. The OAuth provider calls the Wix site URL, passing it an authorization code.
  5. The Wix site backend requests an access token from the OAuth provider using the authorization code.
  6. The Wix site backend requests user information using the access token.
  7. The Wix site backend creates a Wix session token using the user's email address.
  8. The Wix site backend returns a redirect URL to the OAuth provider including the session token.
  9. The OAuth provider redirects the browser using the returned URL.
  10. The browser redirects to the Wix frontend page using the URL.
  11. The Wix site uses the session ID in the URL to log the user in.

Setting up Google

In the Google Cloud Platform, we're going to set up Credentials. Follow this guide to setting up OAuth 2.0 from Google. 

Copy down the Client ID, Client secret and Authorized Redirect URL. We're going to use them later in our code.

Using the Secrets Manager

We'll use the Wix Secrets Manager to securely store our client secret. This is more secure than pasting it to our backend code. Make sure never to expose your client secret.

In the Secrets Manager, store a new secret with the following values:

  • Name : clientSecret
  • Value: The client secret value you retrieved from the Google Cloud Platform dashboard in the previous section.
  • Description:  Something to help you remember what this secret is used for.
If you haven't used the Secrets Manager before, here's how to use it.
  1. Go to your Wix Dashboard.

  2. Select Developer Tools and then Secrets Manager.

  3. Click the Store Secret button and enter the following details:

  4. Name: The name of the secret to be used in the code.

  5. Value: Paste the text value of the secret.

  6. Enter a brief description to remind you what this secret is used for, and click Save.

Setting up Velo

Before we start coding we need to install the Google APIs package so we can call its functions from our code.

To install a package in the editor:

  1. In the left sidebar of the editor, navigate to Packages & Apps. In Wix Studio, you can find this in the Code tab.
  2. Under npm click Install packages from npm.
  3. Search for "googleapis" and click Install.

Adding the Code

We'll need two code files:

  • OAuth.web.js. Where we will create a connection to Google and generate an authorization URL.
  • http-functions.js. To handle the callback from Google and retrieve the user's details.

Note that you must use the file name http-functions.js to handle the web callbacks but you can call the other file any name you like.

Getting the Authorization URL When the Visitor Clicks "Sign in to Google"

Landing page code


When the site visitor clicks Sign in to Google, our site calls the getAuthUrl function in OAuth.web.js at line 13. We create a connection to the OAuth service provider (Google in this case) and request an authorization URL.

The state variable is then stored for this session at line 18. It will be compared to the state variable that is returned with the session token to prevent anyone copying the returned URL and logging in with another browser.

Our frontend then calls at line 20 to direct the browser to the authorization URL.


First, we retrieve our client secret at line 8, and use our API credentials to connect to Google's OAuth servers at line 17.


Note the googleConfig object in OAuth.web.js.


These are the values from the Credentials page that we set up earlier.
The getAuth function in the redirect is defined in http-functions.js

At line 29 we generate a random value for the state variable, which will be stored by the browser, and compared to the state variable that is returned with the session token. This will prevent anyone from copying the URL with the session token and using it to log in. 

At line 32, OAuth.web.js generates the authentication URL and returns it with the state variable, to our frontend. The frontend calls using that URL to direct the browser to the OAuth provider - line 15 in the landing page code. At this point the visitor sees the Google sign in dialog and enters their user name and password. 

Once Google authenticates the visitor, it redirects back to our site to the URL defined in googleConfig.redirect in our code. We also set up that URL in the Google Cloud Platform console as the authorized redirect URI. From the sample code, this will redirect to the get_getAuth function which is defined in http-functions.js.

Handling the Redirect from Google

In get_getAuth, we retrieve the client secret from the Secrets Manager at line 11. Next, we take the request URL from Google and extract the authorization code, at line 19, and the state variable at line 20. This code is used to get the access token based on our clientId and clientSecret, at line 30. Once we have the access token we use it at line 34, to get the userInfo object from Google.

Using the email address from userInfo, at line 45 we generate a session token using the wix-members-backend function generateSessionToken. This token will allow us to log the user in to our Wix site. If the email address corresponds to an existing member, a session token for logging in that member is generated. If there is no existing member with the specified email address, a new member is created and a session token for logging in that member is generated.



Back to Our Site Page

The last step in the http-functions.js process at line 49, is to return a 302 status to Google, with a redirect URL to our site's signed-in page. The URL includes the session token so that we can automatically log the user in and the state variable to protect against copying the URL. Google passes this back to the browser where our site page code uses the token to log the user in.

On our signed-in page, we take the URL and extract the query parameters, including the session token and the response state variable at lines 8-11. We then remove the query parameters from the URL to make it harder to copy.  At line 17 we retrieve the state variable that we saved before signing in.

On line 20, we compare the saved state variable to the state variable returned in the URL. If someone managed to intercept the returned URL, and paste it into a browser, they would not have the value of the saved state variable. The comparison would fail and they would not be signed in. If the saved state is the same as the returned state, then this is the same browser that made the sign in request, so we can sign the user in, using the wix-members-frontend applySessionToken function, at line 21 below.

Create a new page called signed-in. Make sure that your signed-in page has the correct URL. The URL should be, replacing to suit your site. Follow this guide to set the URL.


Adapting the Code for Your Site

Make the following changes to customize the code to work on your site:

  • OAuth.web.js 

    Line 10 - googleConfig - client id and redirect must be changed for your site URL and Google credentials.

  • http-functions.js

    Line 12 - googleConfig - client id and redirect must be changed for your site URL and Google credentials.

    Line 51 - The Location URL must be changed to suit your site.

Was this helpful?