Enterprise SSO with Microsoft Entra ID

Your company signs people in through Microsoft Entra ID, but ZipLogger still has its own passwords. When someone leaves, IT disables their Entra account and has to remember a separate list of tools with separate accounts.

Enterprise SSO connects a ZipLogger workspace to your own Entra directory over OpenID Connect, and can then make it the only way in. The click-by-click instructions are in the Microsoft Entra setup guide. This post explains how the pieces behave, and what they leave alone.

Enterprise SSO is available on Enterprise plans. We enable it for your workspace when you contact us. Until then, Settings → Security shows a banner saying it is not included in your current plan.

Where it lives

Single sign-on belongs to the workspace and happens on the workspace's own address, https://<workspace>.ziplogger.ai. A workspace Admin sets it up under Settings → Security (/settings/security). Other members see a note that only workspace admins can manage it.

Work from the workspace address, not from app.ziplogger.ai. The redirect URI you register in Entra points at the workspace address, so the test sign-in has to start there. On any other address the test button is disabled and the page links you to the right one.

The page is a stack of cards:

• 1 · Choose your provider: set Provider to Microsoft Entra ID.
• 2 · Register this application with your provider: the redirect URI, https://<workspace>.ziplogger.ai/sso/callback, with a Copy button.
• 3 · Provider settings: Directory (tenant) ID, Application (client) ID, Client secret (Value), Secret expires on (optional), Allowed email domains and the sign-in behaviour settings.
• 4 · Test, turn on, require: the three steps that change how people sign in.
• Rotate the client secret and Linked identities.

Two things trip people up in Entra, and the page warns about both. Register the redirect URI under the Web platform, not Single-page application: ZipLogger finishes the sign-in on its server with the client secret, and Entra only allows that for a Web redirect. And copy the secret's Value, not its Secret ID. The Secret ID is a GUID, and ZipLogger refuses a GUID-shaped secret for Entra.

The directory must be the Directory (tenant) ID itself. common, organizations, consumers or a domain name are refused, because they would accept accounts from other organizations. Every sign-in is checked against that one directory.

Saving and testing

Saving a first configuration changes nothing for anyone. The secret is stored encrypted and never shown again.

Test the configuration signs you in through Entra with the saved settings. Nobody else is affected and no ZipLogger session is created. Entra asks you to sign in even if you already have a Microsoft session; that is on purpose. A successful test links your Entra account to your ZipLogger account, so your Entra email has to match your ZipLogger email and be in an allowed domain. The page then shows Last successful test with the time.

If the test fails, the page explains the likely cause from the workspace audit log (Settings → Workspace → Audit log). token_exchange_failed (400 invalid_request) almost always means the redirect is registered as a Single-page application. 401 invalid_client means the secret is wrong or expired.

Changing the directory, client ID, secret or allowed domains later clears the test, switches the sign-in button off until you test again and turn it back on, and discards any pending secret. The page asks Save and switch the sign-in button off? first. While the button is off, people sign in with a password.

Sign-in button versus required for everyone

These are two separate steps.

Turn the sign-in button on needs a successful test. It adds a way in. Nothing is taken away.

Require single sign-on for everyone removes the other way in, so it has more gates. The page lists what is missing under "Not available yet. First:" until the button is on, the test is current, and your own account has signed in through Entra. It then asks you to tick three confirmations: that you signed in from a private window, that the recovery codes are shown once, and that you know where the recovery page is. If you are the only administrator who has signed in through Entra, it warns you and suggests having a second one do so first.

Before you require it, open a private window, go to the workspace address and sign in with Sign in with Microsoft as a second member, ideally one who is not an Admin. That proves it works for someone other than you.

Requiring single sign-on takes effect at once. The page shows the recovery codes, then signs you out, and you come back in with the Microsoft button.

Recovery codes and /sso/recover

When you require single sign-on, ZipLogger shows eight one-time recovery codes in a card titled Save your recovery codes, with Copy and Download as a text file buttons. They are shown once. Store them somewhere that does not depend on Entra: a printed copy or a password manager you do not sign in to through Entra.

If Entra breaks, or the secret expires and nobody is signed in, go to https://<workspace>.ziplogger.ai/sso/recover. Enter an Admin's address in Administrator email and one unused code in Recovery code, then choose Stop requiring single sign-on.

• The requirement ends and password sign-in works again. The sign-in button stays on, and the configuration is kept.
• Every Admin in the workspace is emailed when a code is used.
• A code works once. A valid code entered with the wrong email is used up anyway, and a refused attempt never says which part was wrong.
• Using one code does not cancel the others. After an incident, choose Generate new recovery codes in the Required for everyone block, or require single sign-on again, which also issues a fresh set.

There is no bypass address, header or parameter. If you have no code, write to support from an Admin's email address and name the workspace. If we turn enforcement off for you, the change appears in your workspace audit log.

People whose account was created automatically on first sign-in have no password. When passwords work again, they choose one with Forgot password on the sign-in page first.

How members are linked

On a person's first sign-in, ZipLogger looks for an account in the workspace with the same email address. The email has to be in one of your allowed domains. If there is a match, the Entra identity is linked to that account. After that the person is recognized by their Entra identity, not by their email, so a changed address does not create a second account.

• Allowed domains match exactly. example.com does not include eng.example.com.
• Domains are checked at the first sign-in only. Someone already linked keeps signing in until you unlink them or disable them in Entra. To control who can use ZipLogger at all, set Assignment required? to Yes on the Entra enterprise application and assign people or groups there.
• Conflicts are refused, never merged. An address that belongs to another ZipLogger workspace, or an account already linked to a different Entra identity, stops the sign-in. Re-creating the app registration in Entra gives everyone new identities, so an Admin has to unlink the old ones first.
• Creating accounts on first sign-in is off by default. With Create accounts automatically on first sign-in on, a person from your directory with an email in an allowed domain gets an account, as long as a seat is free. Role for new accounts is Viewer or Editor. It never grants Admin.

Linked identities lists each person with Linked and Last sign-in, and an Unlink button. While single sign-on is required, you cannot unlink yourself.

What enforcement does not affect

Requiring single sign-on is about people signing in. It does not reach:

• API keys. Ingestion keys, read keys and Grafana access keep working. Your applications keep sending logs even if Entra is down.
• Webhooks.

One thing it does reach that people do not expect: AI assistants connected to the MCP server through OAuth. That connection is authorized with a password, so every such connection in the workspace is ended when you require single sign-on, and none can be made that way while it stays required. Connect assistants with a read API key instead. Connections ended this way stay ended if you later stop requiring single sign-on; people connect again.

Sessions after someone is disabled in Entra

ZipLogger asks Entra who you are when you sign in, and not again after that. A ZipLogger session is a 30-minute access token plus a refresh token that is valid for 14 days and replaced each time it is used, so a session in regular use does not expire by itself.

That means disabling someone in Entra stops their next sign-in but does not end a session they already have. To remove someone, in this order:

1. Disable the account in Entra.
2. Unlink their identity under Linked identities. Their Entra-issued sessions and their MCP connections can no longer be renewed.
3. Remove them under Team. Access already issued lapses within about 30 minutes for a browser session and about 60 minutes for an AI assistant connection.
4. Revoke any API key they created or knew under Settings → API keys. Keys belong to the workspace, so none of the steps above revokes them.

Signing out of ZipLogger does not sign anyone out of Microsoft. On a shared computer, sign out of Microsoft as well.

Rotating the client secret

Entra client secrets expire. When the working secret expires, every Microsoft sign-in to the workspace fails. If single sign-on is required, everyone without a live session is locked out until someone uses a recovery code.

The Rotate the client secret card replaces a secret without switching anything off, even while single sign-on is required:

1. Create a new secret in Entra and leave the old one in place.
2. Paste its Value into New client secret (Value), optionally fill in Expires on (optional), and choose Save as pending secret. Members keep signing in with the old secret.
3. Choose Test the new secret from the workspace address and sign in. The check uses only the new secret and creates no session. The card says "The new secret works."
4. Choose Replace the working secret. The sign-in button and the requirement stay as they were.
5. Delete the old secret in Entra.

A pending secret has to be tested before it can replace the working one, and one saved more than seven days ago can no longer be used: choose Discard the pending secret and save it again. Do not paste a new secret into 3 · Provider settings instead. That switches the sign-in button off, and while single sign-on is required it is refused.

If you record an expiry date, Settings → Security shows a warning from 30 days before it, when someone opens the page. ZipLogger sends no reminder, so put the date in your own calendar too.

What it does not do

• SAML and SCIM are not available. Enterprise SSO uses OpenID Connect, and people are added under Team or by automatic account creation.
• No sign-in from Entra's app launcher. Sign-in starts at the workspace address.
• No single sign-out.
• One identity provider per workspace.
• Microsoft Entra ID is the supported provider. Google Workspace and other OpenID Connect providers are available on request; they are built but not yet validated with a live provider, so talk to us before relying on one.

Next step

Follow the Microsoft Entra setup guide step by step, and keep the single sign-on section of the docs for reference. To have Enterprise SSO enabled for your workspace, contact us.