Sign in to ZipLogger with your own identity provider.

One workspace, one provider

Each workspace has its own connection to one identity provider and its own policy. A policy set in one workspace never applies to another.

Your provider proves who signs in

ZipLogger uses the OpenID Connect authorization-code flow with PKCE. Your provider authenticates the person under your own sign-in rules, such as multi-factor authentication, and ZipLogger verifies the signed result before it opens a session.

Test first, require later

Nothing changes for anyone until an administrator has tested the connection and turned the sign-in button on. Requiring it is a separate, optional step with its own confirmation.

Allowed email domains

The workspace lists the email domains it accepts, such as example.com. The list decides whose first sign-in may be linked to an existing account or create a new one. Matching is exact: example.com does not include a subdomain such as eng.example.com, so list each domain.

Domains are checked at a person’s first sign-in. With Microsoft Entra ID, someone who is already linked keeps signing in until an administrator unlinks them or you disable them in your provider. Google Workspace is the exception: it also checks the account’s Workspace domain on every sign-in.

Account linking

On a person’s first sign-in, ZipLogger links their provider identity to the ZipLogger account that has the same email address. After that the person is recognised by that identity, not by their email, so a changed address does not create a second account. If an address already belongs to a different ZipLogger workspace, or to someone with a different provider identity, the sign-in is refused instead of merged.

Just-in-time accounts (optional)

Off by default. When on, a person from your directory with an email in an allowed domain gets an account on their first sign-in, as a Viewer or an Editor, whichever you choose. It never grants Admin, and it respects your plan’s seat limit. An existing Admin promotes people to Admin.

Recovery codes

• Requiring single sign-on shows eight one-time recovery codes, once. Store them offline, somewhere that does not depend on your identity provider.
• At /sso/recover on your workspace address, an Admin’s email plus an unused code ends the requirement. We email every Admin in the workspace when that happens; the recovery itself does not depend on the email being sent.
• Each code works once, and a valid code entered with the wrong email is spent anyway. A refused attempt never says which part was wrong.
• While single sign-on is required, an Admin can generate a new set (Generate new recovery codes, in the Required for everyone block), which replaces the old one.

If you have no code

• Write to [email protected] from an Admin’s email address and name the workspace.
• If we turn enforcement off for you, the change is recorded in your workspace audit log.
• There is no bypass address, header or request parameter for members.

How sign-in is protected

• Each attempt carries a single-use state value and a nonce, uses PKCE, and expires after ten minutes.
• The signed ID token is verified against your provider’s published keys, including its issuer and audience. For Microsoft Entra ID the connection is pinned to your directory.
• The client secret you enter is stored encrypted, bound to your workspace, and is never displayed again.
• A sign-in can only resolve, link or create an account inside the workspace it started in.

What is recorded

The workspace audit log records configuration changes, tests, switching SSO on and off, enforcement, recovery code use, linking and unlinking identities, account creation, and sign-ins, successful and failed. Client secrets, codes and tokens are never written to it.