Skip to content
New: GA4 dashboards, server-side conversions to every ad platform, Consent Mode v2 generation, and publish approvals.See what shipped
TagEasy

Documentation

Setup, platform installs, monitoring, and the API. Written to be followed, not skimmed.

Security: two-factor authentication and SSO

Two layers protect a TagEasy account beyond the password. Any user can add a second factor from an authenticator app, and an organization can require it for every member. Enterprise organizations can also connect SAML 2.0 single sign-on so members sign in through the company identity provider and never hold a TagEasy password at all.

Two-factor authentication (TOTP)

TagEasy uses time-based one-time passwords (RFC 6238): 6 digits, a new code every 30 seconds, SHA-1. Any authenticator app works: 1Password, Google Authenticator, Microsoft Authenticator, Authy, Bitwarden.

Turn it on

  1. Open Settings → Security and click Set up authenticator app.
  2. Scan the QR code, or type the manual key into your app.
  3. Enter the 6-digit code the app shows to confirm.
  4. Save the ten recovery codes. They are shown only once; each signs you in a single time if you lose your device.

Signing in

After the password, the login form asks for the code. The same step applies to Sign in with Google: the Google login completes, then TagEasy asks for your code before anything else loads. A code is accepted once; re-using it, or an older code from the drift window, is refused.

Recovery codes, turning it off

On the Security tab, enter a current code to regenerate recovery codes (the old set stops working) or to turn two-factor off. If you have neither the device nor a recovery code, an organization admin can reset your two-factor from Settings → Members; you then sign in with your password alone and enrol again.

Requiring two-factor for an organization

Admins and owners can switch on Require two-factor authentication for all members on the Security tab. From then on a member without a confirmed authenticator is sent to the Security tab with a banner on every page until they enrol; the rest of the dashboard and the API are unavailable to them. The tab lists who has not enrolled yet so you can warn people before flipping the switch.

The requirement is read from the session, which is refreshed at sign-in, after enrolment, and at most every ten minutes otherwise, so a newly enabled policy reaches signed-in members within minutes.

Single sign-on (SAML 2.0)

SSO is service-provider initiated: the member starts at the TagEasy login page, clicks Sign in with SSO, enters their work email, and is sent to your identity provider. After a successful login the IdP posts a signed assertion back to TagEasy, the user is created or matched by email, added to the organization, and signed in. Multi-factor policy is the IdP's job in this flow; TagEasy does not ask for a second code after SSO.

Connect your identity provider

  1. In Settings → Security → Single sign-on, copy the SP entity id, ACS URL and metadata URL into a new SAML application in your IdP. Set the NameID format to email address and make sure assertions are signed with SHA-256. Optional attributesgivenName / surname (or the Microsoft claim URIs) fill in the user's name.
  2. Paste the IdP's entity id, SSO URL(HTTP-Redirect binding) and signing certificateinto TagEasy, list the email domains the IdP is trusted for, and pick the role new users get.
  3. Click Test configuration, then Save and enable. Try it from a private window with Sign in with SSO before enforcing anything.

What TagEasy checks on every assertion

  • The assertion's XML signature against the stored certificate.
  • That it answers a request TagEasy issued (InResponseTo), has not been seen before, and is inside its validity window (two minutes of clock drift allowed).
  • That the audience is this organization's SP entity id and the issuer is the configured IdP.
  • That the asserted email belongs to one of the listed domains. An IdP is never trusted for domains it was not given.

Enforcing SSO

With Enforce SSO for these domains on, password and Google sign-ins for those email domains are refused and the login form points the user to SSO. Owners of the organization are exempt: they can always sign in with a password, so a misconfigured or expired IdP certificate can be fixed without a support ticket. Creating a new password account on an enforced domain is still possible, but it cannot sign in with that password.

Removing SSO

Deleting the connection stops SSO sign-ins immediately. Accounts that were created through SSO have no password; they can set one with Forgot password on the login page.

Where to see what happened

Every change is on the organization's Activitytab: two-factor enabled, disabled or reset by an admin, a recovery code used, the 2FA policy toggled, SSO connection changes, SSO logins and users provisioned through SSO. Secrets and codes are never stored in the log.