Windows Active Directory to a HubSpot knowledge base, with one login

The constraint everything hinges on

Kerberos and NTLM, the protocols behind Windows Integrated Authentication, stop at the customer’s network boundary. HubSpot’s private content single sign on speaks SAML or OIDC and can only talk to an identity provider it reaches over the internet, so a customer’s own Active Directory can never be that identity provider directly. HubSpot also stopped offering JWT single sign on to new apps in February 2025.

The design starts from one hard constraint: nothing may be installed or configured at customer sites. That rules out the usual bridges, such as AD FS, Entra Connect and agents on customer servers.

That leaves one workable trust path. The WPF app already holds the authenticated Windows identity, so it asserts that identity to a central service run by the app’s owner, and HubSpot trusts only that service. Identity travels outward from the app instead of the cloud reaching into Active Directory.

The handoff, end to end

1. The WPF app reads the user principal name from the Windows session.
2. It sends the central identity provider an assertion signed with its site key, carrying the user, the site and a nonce.
3. The identity provider answers with a one time token that lives for 60 seconds and works once.
4. The app opens the default browser at the identity provider’s start address with that token.
5. The browser redeems the token and the identity provider sets its session cookie.
6. The identity provider redirects the browser to the knowledge base.
7. The browser asks for the knowledge base page.
8. HubSpot sends the browser to the identity provider for OIDC authorization, which completes silently because the session already exists.
9. HubSpot receives an id_token with the verified email and opens the knowledge base session.

One Windows login and no prompt after it. The user never sees a password, a magic link or a registration email. HubSpot receives a standard OIDC id_token whose verified email claim matches the contact record, then applies segment permissions exactly as configured.

Segments do the authorization

Email domain never decides site access. The central service holds the mapping from user principal name to contact to customer and site, writes it to HubSpot contact properties through the CRM API, and segment membership follows those properties. Two users on the same customer domain can hold different site permissions, one user can sit in several segments, and removing a contact from a segment revokes access on the next request.

What changes in the WPF app

One small client update, shipped through the app’s existing update channel, ClickOnce in this case. No customer Active Directory is touched: the app only reads the identity Windows already established.

// Identity: read, never re-authenticate
var upn  = UserPrincipal.Current?.UserPrincipalName
           ?? WindowsIdentity.GetCurrent().Name;

// Assertion: signed with this site's provisioned key (rotatable, revocable)
var payload = new { upn, site = Config.SiteId, nonce = Guid.NewGuid(), iat = Now() };
var assertion = Sign(payload, Config.SiteKey);          // HMAC-SHA256 or per-site cert

// Exchange for a one-time token, then hand off to the default browser
var ott = await idp.PostAsync("/handoff/token", assertion);
Process.Start(new ProcessStartInfo {
    FileName = $"{Config.IdpUrl}/start?ott={ott}&return={KbUrl}",
    UseShellExecute = true                              // system browser, not embedded
});

The central service, with nothing at customer sites

• OIDC identity provider: ASP.NET Core with OpenIddict, with no per seat licensing, registered once in HubSpot’s private content single sign on settings for the knowledge base subdomain. Standard authorize, token and JWKS endpoints, with PKCE enforced.
• Handoff endpoint: checks the site key signature, the nonce and the clock skew, maps the user principal name to the contact email, and issues the single use 60 second token. Site keys are issued per customer install and can be revoked one by one.
• Contact and segment sync: keeps customer and site properties on HubSpot contacts through the CRM API. Segment membership follows the properties, so access stays managed inside HubSpot.
• Audit and revocation: every handoff is logged with who, which site and when. Removing a contact from a segment or revoking a site key takes effect on the next access.

What the design guarantees

• One Windows login and no second prompt: the token redemption and the OIDC round trip are invisible redirects.
• No registration email, password, magic link or self registration: access groups and membership registration are never used.
• Nothing installed or configured at customer sites: the only change is the WPF update through its ClickOnce channel.
• No Entra migration, no AD FS, no Entra Connect and no change to any customer Active Directory.
• HubSpot stays the knowledge base, with its home page, search, categories and articles, and stays the point of enforcement: direct links, private windows and copied links all meet the same OIDC gate and segment check. Articles a user may not see are not rendered, titles included, and protected content stays out of search indexes.

The flows and code are the design as written in August 2026. Three HubSpot facts were checked against HubSpot’s documentation in August 2026: SAML and OIDC support, private content gated by segments, and the end of JWT single sign on for new apps.