All Collections
Getting started with Alva
Managing your account and organizational settings
Authentication settings and Single Sign-On (SSO)
Authentication settings and Single Sign-On (SSO)

Learn how to change your authentication settings and require your employees to sign in using Google, Microsoft or Okta

S
Written by Samuel Lie
Updated over a week ago

If you are an administrator you can access the Authentication settings page under Settings to change authentication settings. These settings will apply to any of your invited employees.

By default Alva supports signing in with either:

  • Email and password combination

  • Google

  • Microsoft

  • Okta

Why change authentication settings?

By changing authentication settings you can make sure that your employees all sign in using the same method. This can be benifical if your company uses Google Workspace, Microsoft Azure/Office 365 or Okta Workforce Identity Cloud to manage your company emails.

By requiring your users to sign in with any of our supported SSO providers your employees will lose access to Alva as soon as their Google, Microsoft or Okta account has been deleted.

Your employees will still need to be invited to access Alva, regardless of authentication settings.

Require sign-in using Google

In the Authentication settings page select Employees must sign in with Google. If you are not signed in with Google, you will be asked to sign in with Google before the setting gets changed.

After the setting is changed, new and existing employees will be asked to sign in using Google when trying to access the organisation. Employees need to sign in with a Google account that matches the invited email address.

If you previously required employees to sign in with a different SSO provider than Google, you first need to allow any sign-in method before you are able to require Google sign-in.

Require sign-in using Microsoft

In the Authentication settings page select Employees must sign in with Microsoft. If you are not signed in with Microsoft, you will be asked to sign in with Microsoft before the setting gets changed.

After the setting is changed, new and existing employees will be asked to sign in using Microsoft when trying to access the organisation. Employees need to sign in with a Microsoft account that matches the invited email address.

If you previously required employees to sign in with a different SSO provider than Microsoft, you first need to allow any sign-in method before you are able to require Microsoft sign-in.

Require sign-in using Okta

The Okta integration is slightly different than the other SSO integrations, and require two steps to be configured properly.

Step 1 - Create and configure the Okta application

First you need to create a Single Sign On (SSO) application in your Okta organization. In order to do so, follow the steps below which we go through in the attached video.

Enter Okta and initiate application creation

  1. Visit https://{yourOktaDomain}/admin/apps/active

  2. Click “Create App Integration” and a dialog will appear

Setup application

  1. Create application dialog:

    1. Sign in method: Choose “OIDC - OpenID Connect” and click “Next”

    2. Application type: Choose “Single-Page Application” and click “Next”

  2. General settings:

    1. Name: Choose a suitable name for your application, e.g. “Alva SSO”

    2. Logo (optional): Choose a suitable logo for your application

    3. Grant type: Make sure the only checked option is “Authorization Code”

    4. Sign-in redirect URIs: There should be one configured URI and that is https://app.alvalabs.io/verify-oidc-authentication

    5. Sign-out redirect URIs: Click the “x” button to remove the configured URI

  3. Trusted origins: Click the “x” button to remove any configured URI.

  4. Assignments:

    1. Controlled access: Choose “Allow everyone in your organization to access”

    2. Enable immediate access: Enable the setting by clicking the checkbox

Submit and collect app credentials

  1. Click “Save”

  2. In your newly created app, there is a “General” tab, click that and your should see a box saying “Client credentials”. Copy the value next to “Client ID” to your clipboard and save it for later

  3. In the top right corner of the web app you should see your username and something like “{yourCompanyName}” below. Expand the menu and click “{yourCompanyName}.okta.com” to copy it to the clipboard. This is your Okta domain - save this value for later

  4. Reach out to Alva's customer support with your Okta domain and your client ID and they will contact Alva’s IT team which will setup your integration in Alva

Note: The recommended “assignments” settings will make sure that all users in your Okta organization have access to login with this app. If you want more granular settings and limit SSO to specific individuals, please check the “assignments” tab for your app and configure them according to your preferences.

Step 2 - Require Okta as a sign-in method

In the Authentication settings page select Employees must sign in with Okta (this button is not visible if you did not complete step 1). If you are not signed in with Okta, you will be asked to sign in with Okta before the setting gets changed.

After the setting is changed, new and existing employees will be asked to sign in using Okta when trying to access the organisation. Employees need to sign in with a Okta account that matches the invited email address.

If you previously required employees to sign in with a different SSO provider than Okta, you first need to allow any sign-in method before you are able to require Okta sign-in.

Frequently asked question:

Question: SSO usually requires some set-up so that our identity provider recognizes Alva as a legitimate source of users – and also that Alva recognizes our identity provider – as a legitimate source of users, by exchanging certificate information in the setup process. Is there not more that I need to do to set up SSO?

Answer: Customers who ask us this are often used to SSO using the SAML protocol. SAML requires a few more steps to set up. We on the other hand are using OIDC, which is a simpler protocol where Azure AD handles all the certificates so that you don't have to do a configuration. You will however need to configure your Azure AD instance to allow the federation of identities to the Alva App. This process can be done by simply signing in to Alva using the Microsoft (Azure AD) SSO. Depending on how the Azure AD instance is configured, this first login needs to be done by an Azure AD administrator. Usually, regular accounts don’t have access to approve usage of the Alva App. This is all the configuration that is needed on your end in Azure AD

Alva support:

Leverage the intercom to chat with an Alva representative for support. You will find this symbol in the bottom right corner on the platform.

Did this answer your question?