For teams sharing AI-generated HTML, dashboards, lead lists, reports, and client deliverables, single sign-on is not a checkbox for the security questionnaire. It is the connection between your identity provider and the place sensitive content is actually being published. Done well, it gives employees a fast path into the tool and gives IT a defensible way to control who can create, view, administer, and audit shared material.
This post is written for the person who has to walk a sharing tool through IT review: what SAML actually proves, what it does not cover on its own, how HTMLvault packages it, and the evidence you need on hand before the review meeting.
What SAML SSO for sharing tools actually does
SAML, or Security Assertion Markup Language, is a standard that lets an identity provider authenticate a person to a service provider. Your identity provider is the system that already knows who works at the company and which groups they belong to. The sharing platform is the service provider that receives a signed SAML assertion confirming that identity.
In practical terms, a user selects the approved sharing tool from the company application portal. The identity provider verifies them using the organization's existing authentication policy, then passes the tool the identity information it needs to start a session. The user does not create a separate account, maintain another credential, or ask a workspace owner to manually add them after every reorganization.
That matters most when the tool holds material that looks harmless until it is not: an HTML pricing page with customer-specific terms, a generated lead list containing work emails and phone numbers, or a dashboard with API credentials accidentally left in a code block.
SSO also changes offboarding. When an employee is disabled in the identity provider, they can no longer authenticate to the sharing workspace. That is cleaner than relying on a former manager to remember every tool the employee used, especially the ones adopted during a campaign sprint.
Where SSO/SAML sits in the plans
In HTMLvault, SSO/SAML packaging is specific, and it is worth getting right before you scope the project or quote a number to Finance.
- Enterprise includes SSO/SAML. Nothing extra to buy.
- Teams supports SSO/SAML as a paid add-on, priced per SAML connection. One connection covers one identity provider integration; a second identity provider (a subsidiary on a different tenant, for example) is a second connection.
- Free and Pro do not offer SAML. Pro is a single-operator plan built around unlimited links, configurable expiry from one hour to never, retention from auto-delete to two years, unlimited per-link channels, and one white-label domain.
Teams is the usual starting point for a governed rollout, because the governance features IT asks about — flat seat bands, custom roles, and audit logs — are part of the plan itself, not of the SSO add-on. That distinction matters in a review: you can demonstrate role separation and an audit trail on Teams before the SAML connection is ever purchased, then add SSO when identity centralization becomes the requirement.
There is no email-and-password login anywhere in the product, on any plan, by design. Users authenticate with Magic Auth (a one-time link sent to a verified address) or a passkey. SAML sits alongside those as the enterprise path, which means adopting SSO does not introduce a password database you then have to defend in a security review — there was never one to begin with. That is a useful line to have ready when the questionnaire asks how credentials are stored.
Setup runs through the WorkOS Admin Portal
SAML configuration in HTMLvault is self-serve. A workspace administrator generates an Admin Portal link, and the identity provider administrator completes the connection through the WorkOS Admin Portal — a guided setup flow with provider-specific instructions and the metadata values needed on each side.
Practically, that means you are not waiting on a scheduled implementation call to get a connection live. It also means the two people involved can be different people: the person who owns the HTMLvault workspace does not need admin rights in the identity provider, and the identity administrator does not need a seat in HTMLvault to finish the setup. For most reviews, this is the answer to "how long does SSO take to stand up" — an afternoon, not a project.
Once the connection is verified, users reach the workspace through your identity provider using the authentication policy you already enforce there, including whatever multi-factor requirement applies to business applications.
SSO is necessary, but it is not content security
A common mistake is treating SSO as the entire control plane. It governs access to the application. It does not automatically determine what happens after someone publishes a link.
A sharing tool still needs controls at the link and workspace level. A user who is properly authenticated may still publish content with an expiry date, password protection where appropriate, a defined data-retention window, and rules around whether the content can be shared externally. Sensitive data should be inspected before publication, not merely protected by a login after the fact.
HTMLvault, for example, combines SSO/SAML with automatic secret scanning and regex-based PII detection. The scanner runs as a deterministic pattern match, so it costs nothing per scan and returns findings immediately. It covers nine categories: SSN, financial data, API keys, passport numbers, addresses, person names, dates of birth, email addresses, and phone numbers — each flagged for one-click redaction before you publish.
Teams and Enterprise customers can add an optional AI scan layer on top of the regex pass by connecting their own Anthropic, OpenAI, or Google API key. That layer catches context the pattern matcher cannot — a paragraph that describes a customer's renewal terms without matching any single pattern. Because the key belongs to the customer, the tokens are billed to the customer; HTMLvault funds none of them. The regex scan remains the default and requires no key at all.
The distinction is useful in a security review. SAML answers, "Can this person use the workspace?" Publishing rules, scanning, expiry, and retention answer, "What can leave the workspace, for how long, and under what conditions?" A reviewer who only hears the first answer will keep asking the second question in different words.
Decide what your identity provider should control
Before configuring SAML, define the boundary between identity governance and workspace governance. The cleanest approach is usually to let the identity provider decide who may enter the application, while the sharing platform decides what those authorized users may do inside it.
Start with the minimum information the service provider needs in the SAML assertion. This commonly includes a stable unique identifier, such as an immutable employee ID or approved work email, plus first and last name if the platform uses them for account display. The exact attributes depend on the platform, but the principle is stable: use a durable identifier rather than a value likely to change after a name change or domain migration.
Then decide whether group information should drive access. A small team may only need an allowlist for all active employees. A larger organization may want separate identity-provider groups for workspace administrators, publishers, and limited users. Group-driven access reduces manual permission work, but it should not become a maze of nearly identical groups that nobody can explain during an audit.
Custom roles and permissions belong here as well, and on Teams and Enterprise they are yours to define rather than a fixed list. An administrator may manage organization-wide publishing rules and audit settings. A publisher may create and update links. A more limited role may view approved content without changing retention or distribution settings. The right split depends on the workflow. Marketing may need broad publishing rights on a branded domain, while a contractor handling a client deliverable may need a narrower scope and a short retention period.
Configure SAML with an offboarding test in mind
The setup itself is guided, but it still deserves a deliberate test plan. In the Admin Portal flow, your identity administrator selects the provider, exchanges the metadata values, and maps attributes. On the identity provider side, assign a small pilot group and require the authentication policy your organization expects for business applications.
Do not assign the entire company first. Test with people who represent actual use cases: a workspace administrator, a frequent publisher, and a person whose access should be restricted. Confirm that a new authorized user can enter the workspace, receives the correct role, and can publish only within the intended rules.
Then run the test organizations often skip: disable a pilot user in the identity provider and verify that they cannot start a new session. If your security policy requires existing sessions to end promptly, validate that behavior too. SAML configurations vary, and a successful login test does not prove that offboarding meets your requirements.
Also document who owns the certificate lifecycle. SAML signing certificates expire. If the certificate is managed as a one-time IT project rather than an operational responsibility, an otherwise healthy integration can fail on an inconvenient Monday morning, usually while someone is trying to send a board report.
What to bring to the IT review
Most sharing tools fail review not because they are insecure but because the person championing them cannot answer the questions in the order they are asked. Have these ready — the enterprise sharing checklist covers the same ground in procurement order:
- How people authenticate. SAML through your identity provider, with Magic Auth or passkeys as the non-SAML paths. No password store exists in the product on any plan.
- How SSO is licensed. Included on Enterprise; a paid add-on priced per SAML connection on Teams. Know how many connections your organization actually needs.
- Who can do what. Your intended custom-role split, and which roles can change retention or read the audit log.
- What gets logged. Audit logs on Teams and Enterprise, showing workspace activity for access reviews.
- What happens before publish. Regex secret and PII scanning across nine categories, at zero token cost, with optional BYOK AI scanning on Teams and Enterprise using your own provider key.
- What happens after publish. Configurable expiry, password protection, data-retention windows down to auto-delete, and links that are never indexed by search engines.
- How offboarding works. Your documented test result, not an assumption.
That list is the difference between a review that ends in an approval and one that ends in a follow-up meeting.
A concrete workflow for an AI-generated proposal
Consider a RevOps team using an AI assistant to generate an HTML proposal from approved pricing data. The assistant calls the API directly — through MCP tools such as scan_html and create_link from Claude, a Custom GPT action, or a Zapier step — so the finished page becomes a secure link rather than an attachment or a paste into an unsanctioned tool.
The publisher enters through SAML SSO, so access is tied to their company identity. Before publication, secret scanning checks for credentials that may have been included in generated code. PII detection flags a prospect contact's personal details if they appear in the draft, giving the publisher a chance to redact them. The link is configured with an appropriate expiry and retention period, and it is served on the company's branded subdomain or custom domain.
Sales can then use per-recipient tracked URLs to distinguish engagement across stakeholders. Total and unique views, repeat visits, time on page, scroll depth, device, browser, geography, referrer, and server-side channel attribution provide useful context without requiring the team to send a revised attachment every time a paragraph changes. If the proposal should stop being available, the workspace policy and link controls matter just as much as the user's authenticated session.
This is the operating model IT wants: users move quickly, but they do so inside a controlled system with a record of what was shared and by whom.
Keep external sharing separate from internal login
One nuance deserves attention. SAML SSO protects access to the publishing workspace, not every recipient who opens an externally shared link. That is usually the point. A prospect should not need an account in your company identity provider to read a proposal.
For external content, use the controls appropriate to the sensitivity and audience. Password protection can help when a link needs an additional barrier. Expiry limits how long it remains useful. Retention rules determine when the underlying content is deleted. Never-indexed links keep shared pages out of search engines and AI crawlers, but they are not a substitute for access controls when the content is highly sensitive.
This separation avoids an unhelpful choice between two bad extremes: making every external recipient complete an internal login flow, or treating public-link behavior as an afterthought.
Avoid the two predictable failures
The first failure is SSO without authorization design. Everyone can log in, but no one has agreed who may publish lead lists, change retention settings, or administer organization-wide rules. The result is a sanctioned tool that still behaves like a shared junk drawer.
The second is authorization design without adoption. If the approved workflow is slow, unclear, or limited to a handful of manually provisioned users, teams will route around it. They will paste a report into a public pastebin, send an attachment, or use a flashy unsecured tool because the deadline feels more real than the policy.
The answer is not more warnings. It is a workflow that is easier than the workaround: passwordless entry through the company identity provider, clear roles, secure publishing defaults, and analytics that help the business user do their job.
Get this right and the IT lead has what they actually need to sign off — a named authentication path, a defensible role split, an audit trail, and a documented offboarding test — while the rep, the marketer, and the RevOps analyst keep publishing at the speed the deadline demands. Nobody has to choose between the fast path and the approved one, because for the first time they are the same path.