Settings for SSO must be adjusted by an admin through the Dashboard. From the left sidebar, click into Account -> Settings. By choosing the Single Sign-on header, you will be able to see available options for SSO in the form of toggle buttons.

Admins can toggle On/Off to enable or enforce:

Click the toggle button to Enable Azure SSO.

Once Azure SSO has been enabled, admin will be asked to fill in the following values:

Additionally, it will be necessary to input a "redirect URI" into an appropriate field on the interface of the respective identity provider—in this case, Azure. In the following steps, users will be required to login to their Azure Portal from a separate tab in order to obtain the above value references and to input the redirect URI, which is necessary for authorization to work properly.

As a first step, login to your Microsoft Azure account and ensure you are starting from the Azure Portal hosted at portal.azure.com. From the landing page you will see a list of icons under the header Azure services. Click into the pyramid icon labeled Azure Active Directory.

From the choice of tabs listed on the left, select App registrations. If not already done, we will need to click + New Registration to add CloudTalk as a new app registration.

Enter a name for the application (CloudTalk) and select a choice for Who can use this application or access this API.

Enter the Redirect URIs for CloudTalk:

*Important*: Change the dropdown list option on the left from Public client/native (shown) to Web. Click the blue button to Register CloudTalk as an application.

In case you need to add or change the Redirect URI after a CloudTalk application has already been registered, you can do so by clicking the blue text next to Redirect URIs on the Overview tab in CloudTalk's registered application directory.

Once CloudTalk has been registered and the Redirect URI has been added, we can find the other values which will be required to enter during setup on the CloudTalk Dashboard. Make sure to store these values somewhere safe, or have CloudTalk open in another tab to copy and paste them in directly.

The Client ID will refer in this case to the Application Client ID which is viewable within the App Registrations tab right next to the Display name for CloudTalk's registration.

It can also be found after having clicked into CloudTalk's registered application directory, within the Overview tab.

A new Client Secret will have to be created, if not already done. From the App Registrations tab in Azure, click into CloudTalk's registration, which should be highlighted in blue like a link. On Azure's overview page for CloudTalk's app directory, you can click the option to Add a certificate or secret, next to the Client Credentials descriptor.

Another option is to navigate to the left-side tabs, selecting Certificates & secrets. Both pathways redirect to the same page, where there will be displayed any existing certificates we have already generated.

To generate a new client secret, make sure you are under the Client secrets header, and click the + New Client Secret icon.

Enter a Description and an expiration date for the authentication code.

Click Add.

Be aware that the part of the Client Secret needed for copy-pasting is the code within the Value column, as shown below.

Last but not least, we need to get the Discovery URI, not to be confused with the redirect URI we used earlier. For Azure, the discovery URI should have the following format:

There are a few ways we can construct this URI with the correct tenant ID. The preferred method for accuracy is to use the exact format above, and replace {tenant} with the real tenant ID, which can be found either outside the CloudTalk app directory in the Overview or Properties tabs, or within the CloudTalk app directory, in the Overview tab.

One last value we will be expected to enter within the Dashboard->Account->Settings->Single Sign-on fields for Azure is the Method. POST is the advised selection from a choice of GET or POST, though in the case of Azure, the method is usually interchangeable—if the setup with POST does not work, try GET.