Microsoft login for security groups

Security groups protect forms and dashboards with a shared login. Besides username/password and OTP, a group can accept sign-in with Microsoft (Entra ID / Azure AD): the end user signs in with their Microsoft account and Floogos validates their identity against the group’s allowlist.

Different from the Microsoft integration

This login authenticates the person opening the form. It is not the same as connecting a Microsoft account so a workflow node can read mail or calendar (that’s integrations). It uses its own Azure app and its own configuration.

How it works

1. The user opens a protected form or dashboard and chooses Sign in with Microsoft.
2. They authenticate with Microsoft.
3. Floogos receives their email and directory (tenant) and validates them against the group’s configuration.
4. If they pass, a shared session is created, valid for every form and dashboard in that group.

There is a single return URL for all groups, so you only register one URL in Azure even with many groups.

Requirements

• A Microsoft Entra ID directory where you can register the app.
• To be an organization administrator in Floogos, so you can load the credentials under Organization → Security (next step).

Step 1 — Register the app in Azure / Entra ID

1. Azure Portal → Microsoft Entra ID → App registrations → New registration.
2. Name: e.g. Floogos – Forms login.
3. Supported account types:
   • Single directory (your organization only), or
   • Any directory / Microsoft accounts if you’ll allow external accounts (later filtered by allowlist).
4. Redirect URI (Web type), exactly:

   https://YOUR_DOMAIN/f/realm/oauth/microsoft/callback

5. Register and copy the Application (client) ID and Directory (tenant) ID.
6. Under Certificates & secrets → New client secret, copy the Value when created (it isn’t shown again).
7. Permissions: basic identity is enough (openid, profile, email); no admin consent required.

Step 2 — Load the credentials into Floogos

You do this from the application itself, with no server access and nothing to ask support for. It works the same on Floogos Cloud and on-premise.

Under Organization → Security, create or edit a group and tick the Microsoft account (OAuth2) method. The Microsoft config block appears below it:

1. Copy the redirect URI shown in the blue notice and register exactly that one in Azure (step 1). It is the value people get wrong most often.
2. Paste the Application (client) ID.
3. Paste the Client secret — the Value, not the Secret ID.
4. Save application.

The application is registered once per organization, not per group: what changes between groups is the tenant and the allowed domains, not the app.

The secret is never shown again

For security, Floogos never returns the stored Client secret. When editing, the field comes up empty: leave it blank to keep the current one, and type a new value only if you want to replace it.

If the organization has no application registered yet, the dialog says so and the Microsoft option won’t appear on the login (the other methods keep working).

What about the environment variables

These credentials used to live on the server (MS_FORM_CLIENT_ID and MS_FORM_CLIENT_SECRET), which meant editing the configuration and restarting. They still work as a fallback: an installation that already had them needs no changes. As soon as an organization saves its own application from the dialog, that one takes precedence.

The dialog tells you which is in use: if they are the server’s, it says so and explains that filling in the fields switches the organization to its own.

Two variables remain server-side:

Variable	What for
FORM_AUTH_SECRET	Signs sessions and the OAuth state
CONFIG_ENC_KEY	Encrypts the Client secret in the database

Without CONFIG_ENC_KEY it will not save

The Client secret is stored encrypted (AES-256-GCM). If the server has no CONFIG_ENC_KEY, saving shows an explicit warning: Floogos would rather not store the secret at all than store it unencrypted. On Floogos Cloud it is already configured.

Step 3 — Enable Microsoft on the group

In Organization → Security, edit the group:

1. Enable the Microsoft method.
2. Choose the mode:

Mode	Who can sign in	Allowlist
Single directory	Only the directory (tenant) you specify	Optional (if added, restricts further)
Any account (multi)	Any Microsoft account, filtered by the allowlist	Required — with no allowlist, nobody gets in

3. Fill in the allowlist by email or by domain (e.g. company.com). A user is allowed if their email is on the list or their domain matches.

“Any account” with no allowlist

In multi mode, if you add no allowed email or domain, everyone is rejected on purpose, so that not just any Microsoft account can get in.

Troubleshooting

Message	Cause	Fix
redirect_uri_mismatch (Microsoft screen)	The redirect URL doesn’t match Azure	Copy the redirect URI shown in the dialog and register exactly that one in Azure (scheme, domain, path, no extra trailing /).
invalid_state	The state expired or the secret differs across servers	Retry; verify FORM_AUTH_SECRET is the same on all instances.
no_allowlist	Any account mode with no list	Add allowed emails or domains to the group.
not_allowed	The email/domain isn’t allowed	Add it to the group’s list.
no_email	Microsoft returned no email	Ensure the email permission and that the account has an address.
Microsoft button doesn’t appear	The organization has no application registered	Load the Application ID and Client secret under Organization → Security.
AADSTS7000215	Client secret expired or wrong	Regenerate the secret in Azure and paste the new Value into the dialog. Azure secrets expire.
Cannot save: CONFIG_ENC_KEY missing	The server cannot encrypt the secret	Set it on the server. Floogos does not store secrets unencrypted.

Notes

• The Azure client secret expires — note the date and rotate it before it lapses.
• In multi-server deployments, all instances must share the same FORM_AUTH_SECRET and CONFIG_ENC_KEY. The Microsoft credentials live in the database, so they are shared automatically.