Configure SSO

Corporate SSO in Acumbamail

What is SSO and what is it for?

Corporate Single Sign-On (SSO) allows you to restrict access to your landing pages so that only users who belong to your organization can view them. Instead of sharing a generic password, each person authenticates with their corporate Microsoft or Google account, ensuring that only authorized employees or collaborators can access the content.

This is especially useful for landing pages with internal company content, confidential materials, private documentation, or communications intended exclusively for employees.

This feature is available on Acumbamail’s Pro and Enterprise plans.

Preliminary concepts

Before you start the configuration, it is important to understand what data you will need. All these values are obtained from your identity provider’s portal (Microsoft Entra or Google Cloud Console) and are then entered into Acumbamail.

Tenant ID — The unique identifier of your organization in Microsoft. In the Microsoft portal it appears as "Tenant ID". It is only required for Microsoft and is found on the Microsoft Entra ID main page.

Client ID — The identifier of the application you register for SSO. Microsoft calls it "Application (client) ID". It is found on the registered application page, both in Microsoft Entra and in Google Cloud Console.

Client Secret — A secret key that allows Acumbamail to communicate securely with your provider. It works like the application’s password. It is generated in the application credentials section. It is important to copy it when you create it, since it cannot be viewed again later.

Allowed domains — Your organization’s email domains. Only users whose email belongs to one of these domains will be able to access the landing page. You define this (for example: mycompany.com ). If you have several corporate domains, you can separate them with commas: mycompany.com, subsidiary.com .

Configuring SSO with Microsoft (Entra ID / Azure AD)

Microsoft Entra ID (formerly known as Azure Active Directory) is the most common identity service in organizations that use Microsoft 365. Configuration is carried out in two parts: first, an application is registered in the Microsoft portal, and then the data is entered into Acumbamail.

Register the application in Microsoft Entra

In order for Acumbamail to authenticate your organization’s users, you need to register an application in the Microsoft Entra portal. This application acts as a bridge between Acumbamail and your company’s identity service.

Access the Microsoft Entra portal at https://entra.microsoft.com and look for the App registrations section under Identity > Applications. From there, create a new registration with the following details:

Give it a descriptive name that helps you identify it later, for example "Acumbamail SSO" or "SSO Landing Pages".
Under supported account types, select the option that restricts access to accounts in your own organizational directory ("Accounts in this organizational directory only").
Under Redirect URI, select the Web type and enter the Acumbamail callback URL. This URL is where Microsoft will send the user after authentication:

https://<domain or subdomain in acumbamail>/page/sso/callback/

If you use a custom domain for Acumbamail, replace <domain or subdomain in acumbamail> with your domain. If you use an Acumbamail subdomain, replace <domain or subdomain in acumbamail> with your subdomain.

Obtain the Tenant ID

The Tenant ID identifies your organization within Microsoft. To find it, go to your directory’s overview page in Microsoft Entra.

On this screen you will see a field called Tenant ID. Copy this value.

Do not confuse the Tenant ID with the Object ID. The Tenant ID identifies your entire organization, while the Object ID identifies a specific resource (an application, a user, a group). The one you need is the Tenant ID.

Obtain the Client ID

The Client ID is found on the main page of the application you have just registered. Under App registrations, select your application. In the Overview section, you will see the Application (client) ID field. Copy this value.

Generate the Client Secret

The Client Secret is a key that allows Acumbamail to prove its identity to Microsoft. To generate it, within your application settings look for the Certificates & secrets section in the side menu.

Click New client secret, assign it a description (for example "Acumbamail SSO") and select a validity period. When you confirm, a table with the new secret will be displayed.

Very important: copy the Value field immediately. This is your Client Secret and Microsoft only displays it once. If you close the page without copying it, you will have to create a new one. The "Secret ID" field that appears next to the Value is an internal Microsoft identifier and is not used in Acumbamail.

Configure the application permissions

For authentication to work correctly, the application needs permissions to read the user’s basic information. Within your application settings in Entra, go to the API permissions section and make sure the following Microsoft Graph delegated permissions are granted:

openid — allows authentication via OpenID Connect
profile — access to the user’s name
email — access to the email address

If these permissions are not granted for the whole organization, click Grant admin consent to enable them.

Enter the data in Acumbamail

Once you have all the data, go to Acumbamail and access the SSO settings. In the side menu, expand My account and click Preferences. In the top tab bar, select SSO.

Click Add SSO and fill in the form:

Provider: Microsoft (Azure AD)
Name: A name that helps you identify this configuration (e.g.: "Corporate Microsoft SSO")
Tenant ID: The Tenant ID you copied from the Entra portal
Client ID: The Application (client) ID of your registered application
Client Secret: The Value of the client secret you generated
Allowed domains: Your organization’s email domain (e.g.: mycompany.com )

Click Save to complete the configuration.

Configuring SSO with Google

If your organization uses Google Workspace (formerly G Suite), you can configure SSO so that users authenticate with their corporate Google account. The configuration is done from Google Cloud Console.

Create a project and configure OAuth

Access Google Cloud Console and select an existing project or create a new one. Within the project, navigate to APIs & Services > Credentials.

Before creating the credentials, you need to configure the OAuth consent screen. This screen is what users will see when they authenticate for the first time. In the corresponding section:

Select the Internal type, which restricts access exclusively to users in your Google Workspace organization. This is important: if you select "External", any Google account could attempt to authenticate (although Acumbamail’s domain filter would block them anyway).
Fill in the application name (e.g.: "Acumbamail SSO") and a contact email.
In the Scopes section, add openid , email and profile . These permissions allow Acumbamail to know the user’s identity and email address.

Create the OAuth 2.0 credentials

Once the consent screen is configured, go to Credentials > Create credentials > OAuth client ID. Select the Web application type and assign it a descriptive name.

In the Authorized redirect URIs section, add the Acumbamail callback URL:

https://<acumbamail domain or subdomain>/page/sso/callback/

When you confirm the creation, Google will display the Client ID and Client Secret. Copy both values. Unlike Microsoft, Google allows you to view this data later from the credential page, but it is good practice to copy it at the time.

Enter the data in Acumbamail

In Acumbamail, go to My account > Preferences > SSO and click Add SSO. Select Google as the provider. You will see that the form does not show the Tenant ID field, since Google does not need it.

Fill in the fields:

Name: A descriptive name (e.g.: "Corporate Google SSO")
Client ID: The Client ID provided by Google Cloud Console
Client Secret: The Client Secret provided by Google Cloud Console
Allowed domains: Your Google Workspace email domain (e.g.: mycompany.com )

Click Save to complete the configuration.

Protecting a landing page with SSO

Once you have configured at least one SSO provider, you can apply the protection to any landing page. The process is carried out from the landing page editor itself.

Enable protection

Go to Websites in the Acumbamail side menu and select the landing page you want to protect. In the first step of the editor (**Settings**), you will find a section titled "Access only with corporate SSO" with the description: "Only users authenticated in your company’s SSO will be able to access".

Activate the switch by changing it to YES. When you do so, a drop-down menu will appear with the SSO providers you have configured so you can select which one you want to use on this landing page.

If you do not yet have any provider configured, instead of the drop-down menu you will see a link that says "You have no SSO providers configured. Configure one here" and it will take you directly to the SSO configuration screen.

After selecting the provider, save the changes with Save draft or continue to the next step of the editor.

What happens when a user accesses the landing page?

When someone tries to visit a landing page protected with SSO, Acumbamail checks whether they already have an active SSO session. If they do not, they are automatically redirected to the login page of the configured provider (the Microsoft or Google login screen, as applicable).

The user enters their corporate credentials as they normally would to access any other service from their company. Once authenticated, the provider redirects the user back to Acumbamail, which validates the response by checking three things:

That the authentication token is genuine and has not been tampered with.
That the user’s email domain is included in the provider’s Allowed domains list.
That the token has not expired.

If all validations are correct, the user accesses the landing page normally. If any of them fail (for example, if the user has authenticated with a personal account instead of the corporate one), an error page is displayed explaining the reason.

Session duration

The SSO session remains active as long as the authentication token does not expire. The duration depends on the identity provider’s configuration (Microsoft or Google), but it is usually between 1 and 24 hours. Once it has expired, the user will have to authenticate again the next time they access the landing page.

Managing SSO providers

Edit an existing provider

From the My account > Preferences > SSO screen, each provider is listed with its main details and buttons to edit or delete it. When editing a provider, you can modify any field. The Client Secret is optional during editing: if you leave it blank, the current value is kept. This is useful if you only need to change the name or allowed domains without having to look up the secret again.

Delete a provider

You can delete an SSO provider as long as it is not assigned to any landing page. If you try to delete a provider that is in use, Acumbamail will prevent you from doing so with an error message. In that case, you will first need to access each landing page that uses that provider, disable SSO protection, and then try deleting it again.

Use multiple providers

Acumbamail allows you to configure several SSO providers simultaneously. This is useful in situations such as:

A company that uses Microsoft for its internal team but Google Workspace for a subsidiary.
Different landing pages aimed at different audiences, each with its own identity provider.
Keeping a backup provider while migrating from one identity system to another.

Each landing page is associated with a single provider, but different landings can use different providers.

Allowed domains

The Allowed domains field is the key security element of SSO in Acumbamail. Even if a user authenticates correctly with Microsoft or Google, Acumbamail will check that the domain of their email address matches one of the domains configured in the provider.

For example, if you configure acumbamail.com as an allowed domain, a user with the email john@acumbamail.com will be able to access, but someone with john@gmail.com will be rejected even if they manage to authenticate (which should not happen if you have correctly configured the provider as "Internal" or "Single tenant").

You can specify several domains by separating them with commas. This is common in organizations with multiple corporate domains:

mycompany.com, mycompany.es, subsidiary.com

Security considerations

Acumbamail SSO is implemented following the OpenID Connect (OIDC) protocol with authorization code flow, which is the industry standard for delegated authentication. Some relevant technical details:

Client Secrets are stored encrypted in the Acumbamail database using symmetric encryption (Fernet). They are never stored in plain text.
Each authentication flow generates a state parameter (CSRF protection) and a nonce (protection against replay attacks), both validated when the process is completed.
JWT tokens received from the provider are validated with the provider’s JWKS public keys, ensuring that they have not been forged.
The Redirect URI configured in the provider must exactly match the Acumbamail callback URL. If they do not match, the provider will reject the authentication request.
Expired authentication states are automatically deleted after 10 minutes to avoid the accumulation of obsolete sessions.

Troubleshooting

"No SSO providers are configured"

This message appears when you try to enable SSO on a landing page but have not yet created any provider. Go to My account > Preferences > SSO and create at least one provider before enabling protection.

Authentication error

If a generic error appears when trying to access a protected landing page, it is most likely that some of the provider data is incorrect. Check especially:

That the Client ID corresponds to the correct application.
That the Client Secret is the Value (not the Secret ID) and that it has not expired.
That the Tenant ID (in Microsoft) is your organization’s ID (Tenant ID), not the application’s Object ID.
That the Redirect URI configured in the provider exactly matches https://<acumbamail domain or subdomain>/page/sso/callback/ .

Access denied after successful authentication

The user has authenticated successfully but their email domain is not in the allowed domains list. Check the provider’s Allowed domains field and make sure it includes the user’s email domain.

Cannot delete a provider

This occurs when the provider is assigned to one or more landing pages. First disable SSO on all landings that use it (by changing the switch to NO in their Settings) and then you will be able to delete it.

The Client Secret has expired

Both Microsoft and Google allow you to set an expiration date for Client Secrets. If the secret expires, users will not be able to authenticate. Generate a new secret in the provider’s portal, edit the provider in Acumbamail, and update the Client Secret field with the new value.