Enabling enterprise security suite for AI Hub

Enterprise authentication & authorization: SSO, RBAC, & API access.

๐Ÿ”’ NDA note: customer names and numbers are generalised or removed throughout. No disclosed figures.
๐Ÿ–ฅ๏ธ Product:Instabase AI Hub โ€” multi & single-tenant
๐Ÿ‘ฅ Team:Me (Design lead), 1 PM, 4 Dev, Docs & pre-sales
๐Ÿ’ผ Role:Senior Product Designer
โฑ๏ธ Time:Multiple releases across ~ 4 months

*Prototype video with dummy data

Business impact

Unlocked enterprise deals that named security as a blocker

๐Ÿ’ฐ ARR unblocked:
xx M$ to XXX M$
+40% aprox
๐Ÿข Enterprise orgs won:
0 to 9
New logos
โฑ Initial org setup time
4 Weeks to 5 Days
-87.7%

Source: internal pipeline + org settings telemetry.

Quick context

โ“ Why

  • Enterprise buyers could not pass security review without SSO, IdP-driven access control and short-lived API tokens
  • Deals were being worked around, not won

๐Ÿ” What

  • Self-serve SSO (SAML 2.0 + OIDC) for multi- & single-tenant
  • IdP group mapping driving RBAC
  • OAuth2 Compliant tokens for API access, with scopes

๐Ÿ‘ฅ Whom

  • Org / IT admins configuring identity
  • Platform engineers calling APIs
  • Security architects signing off
  • Instabase presales & support

๐Ÿ›  How

  • Three connected tracks across releases
  • Design decisions driven by threat modelling, not just flows
  • AI used end-to-end for research synthesis & spec drafting

Project brief

My job was to design the identity and enterprise security layer that lets a global enterprise trust AI Hub โ€” put their own identity provider behind it, control who sees what, and issue their own API tokens โ€” prove that trust to their security team, and win the enterprise logo by considering:

๐Ÿ” SSO โ€” SAML 2.0 + OIDC protocol ๐ŸŽŸ OAuth 2.0 / JWT ๐Ÿ”‘ RBAC ๐Ÿ“œ Audit logs ๐Ÿ”— Identity providers Okta Microsoft Entra ID PingFederate Auth0 JumpCloud OneLogin AD FS

Problem statement

An enterprise IT admin evaluating AI Hub is trying to pass their security review, but encounters an app that still authenticates like a consumer product โ€” email + password, Google sign-in, groups managed manuallyone click at a time, and API tokens that never expire and can't be scoped โ€” which makes them feel like the product isn't ready to trust with their organization's data.

Why we're building this

It started as a pattern in the support and presales channels: the same five objections, from the largest accounts in the pipeline, over and over.

๐ŸšงSSO was a tenancy accident

SSO existed only for single-tenant customers. Multi-tenant enterprise customers had no way to connect their IdP โ€” so commercial MT customers were being provisioned an entire single-tenant environment just to get SSO.

"A European luxury retail group was given a single-tenant instance as a temporary workaround while waiting for multi-tenant SSO."

๐Ÿ“„The docs promised what we didn't have

Documentation claimed OIDC group mapping was supported. It wasn't. A top-tier enterprise customer found the gap themselves and raised it repeatedly.

"A large financial institution called out the inaccuracy directly."

๐Ÿ”‘Long-lived opaque tokens

API access relied on raw, long-lived internal tokens. Banks' security policies simply forbid them โ€” they need short-lived JWTs issued and revoked by their own IdP.

"A global investment bank could not use our tokens at all under internal policy."

๐Ÿค–No identity for machines

In an SSO-only org, automation had nowhere to live: no service-account primitive, and a shared "faceless" account cannot complete an SSO login.

"A global security vendor named this a go-live blocker."

๐ŸงฏEverything needed a human

Even after release, SSO required an internal engineer to flip a per-org feature flag. Customers who followed the public docs hit an error and filed a ticket.

"A global insurer and a European media group both landed in support for exactly this."

๐ŸฉธSome security leaks

The "Run app with API" sample-code panel rendered live OAuth tokens in copy-pasteable code, over http://. An internal reviewer had to redact a screenshot before sharing it.

"Found internally โ€” fixed as part of this work."

22
distinct enterprise-reported problems catalogued across 4 Slack channels
9
named enterprise accounts blocked or worked around

Three tracks, one identity story

๐Ÿ” Track 1 โ€” SSO
  • SAML 2.0 + OIDC for multi-tenant
  • Self-serve configuration UI
  • Test before you enforce
  • Threat-modelled domain handling
๐Ÿ‘ฅ Track 2 โ€” Group mapping
  • IdP groups โ†’ AI Hub groups
  • OIDC parity with SAML
  • Many-to-one mapping
  • Making sync timing honest
๐ŸŽŸ Track 3 โ€” OAuth tokens
  • Customer-IdP-issued Tokens
  • Account mappings per identity
  • Scopes that only downscope
  • Deprecating raw internal tokens

Who I designed for

Identity features have an unusual audience: the person who configures it is rarely the person who uses the product, and the person who approves it never logs in at all.

Primary focus
๐Ÿง‘โ€๐Ÿ’ผOrg / IT admin

Sets identity up โ€” and can break it for everyone.

  • Configures SSO inside AI Hub
  • Mirrors the same config in Okta / Entra / Ping
  • Owns group → role mapping
  • Decides when to enforce SSO org-wide
  • Tracks all audit logs
Primary focus
๐Ÿ‘ฉโ€๐Ÿ’ปPlatform engineer

Runs everything that talks to AI Hub without a human.

  • Automates AI Hub through the API
  • Needs a non-human identity to act as
  • Lives inside token expiry and scope rules
  • Judges us on the first successful API call
Influences
๐Ÿ›ก๏ธSecurity architect

Approves the purchase. Never opens the product.

  • Runs the vendor security review
  • Sets the policy the admin must meet
  • Can veto the whole deal
Affected
๐Ÿ™‹End member

Feels every configuration mistake, fixes none of them.

  • Just wants "Continue with SSO" to work
  • Should never see a SAML error string
  • Needs right group access
Internal
๐ŸŽงInstabase support

Absorbs every gap the product leaves open.

  • Debugs failed logins with little visibility
  • Enables per-org feature flags by hand
  • Owns the escalation the customer never wanted
Internal
๐Ÿ“ฃPresales & Docs

Has to state our security posture, live, on a call.

  • Answers "do you support X?" in real time
  • Needs a defensible security story
  • Pays for every capability we overstate

Where I focused: the two highlighted roles operate the system โ€” everyone else shaped it as a constraint, not a screen.

The ecosystem โ€” how these six are connected

Identity is never one person's job โ€” it's a chain of approval, dual configuration, and consequence. Mapping it is how I found which problems were actually design problems.

CUSTOMER ORGANISATION INSTABASE ๐Ÿ›ก๏ธ Security architect Approves. Never logs in. ๐Ÿง‘โ€๐Ÿ’ผ Org / IT admin Configures both sides. ๐Ÿ‘ฉโ€๐Ÿ’ป Platform engineer Automates via the API. ๐Ÿ™‹ End member Just wants to sign in. Customer IdP Okta ยท Entra ยท Ping User directory Groups MFA policy Token issuance the system we do not control AI Hub what I designed SSO configurations Group mappings โ†’ RBAC OAuth providers Account mappings Token validation Audit logs Entitlement gate: Enterprise tier + per-org flag + org-admin role ๐Ÿ“ฃ Presales / SE Answers "do you support X?" ๐ŸŽง Instabase support Only one who can see truth. 1 2 3 4 5 6 7 8 9 10 11
The security review gates the dealNever opens AI Hub โ€” but their review decides if presales can close.
Policy flows down to the adminWhatever the architect mandates, the admin has to configure.
Admin registers AI Hub inside the IdPHalf of "setting up SSO" happens in a product we don't own.
Admin configures the AI Hub sideSame values, different vocabulary โ€” the mismatch is where most setup failures live.
The trust handoffIdP signs, AI Hub validates. The exchange this whole project is built around.
Machines get credentials from the same IdPShort-lived JWT โ€” no human, no password, no login.
Automation calls the APIBearer token, scoped by role UUIDs, mapped to a service account.
The member just signs in"Continue with SSO" โ€” they're the first to hit any error underneath.
Support flips the flagUntil an engineer enables the per-org flag by hand, the customer sees an empty screen.
Every failure escalates back to usAdmins and members both land here โ€” the source of the 22-issue research log.
Presales hands the promise to supportWhatever was claimed becomes support's problem if the product can't back it.

Hover (or tab to) the numbered markers above for the story behind each connection.

๐Ÿ”€ Setup is split across two products

โ‘ข and โ‘ฃ are the same configuration in two vocabularies. Neither side can validate the other. That gap is why field labels now carry each IdP's own naming.

๐Ÿ‘ค The approver never logs in

โ‘  is a design surface with no interface. The capability matrix, the validation flow diagram and the honest gap list were built for someone evaluating risk, not operating a UI.

๐Ÿ” Every gap ends at support

โ‘จ, โ‘ฉ and โ‘ช form the friction loop this project attacked: invisible entitlement, silent errors, and no self-serve activation.

Let's look at what happened before

Three broken paths

I mapped the three journeys the enterprise identity story runs through today โ€” logging in, getting access, and calling the API โ€” and marked every point where a customer had actually reported failure.

๐Ÿ”„ Path A โ€” a user signs in

User enters email + password created inside AI Hub

Enterprise IdP, MFA policy and offboarding rules are bypassed entirely

Admin manually invites and removes every member

Leaver keeps a working password until someone remembers to delete them

๐Ÿ”„ Path B โ€” a user gets the right access

Admin creates AI Hub groups by hand

Adds each member to each group, manually

Repeats forever as people join, move teams and leave

Access drifts out of sync with the org chart โ€” an audit finding waiting to happen

๐Ÿ”„ Path C โ€” a system calls the API

Engineer generates a long-lived opaque token in the UI

Pastes it into a pipeline, a notebook, a shared vault

Token carries the full permissions of its human owner, forever

No expiry, no rotation, no revocation from the IdP, no scope

๐Ÿ”„ Path D โ€” No Adudit logs

Accessing audit logs requires internal engineer's help

SOC 2 security blockers

Track 1 โ€” Self serve Single Sign-On for every tenant

๐Ÿง‘โ€๐Ÿ’ผ The org / IT admin

๐Ÿ˜“ Pain points

  • Configures SSO maybe twice in a career โ€” no muscle memory for SAML
  • Field names in AI Hub don't match field names in their IdP
  • Errors appear at login time, not at configuration time
  • Terrified of locking their whole organisation out

๐Ÿ”‘ Needs

  • Setup in the language of Okta / Entra, not the language of SAML
  • A safe way to test before enforcing
  • Clear required vs optional attributes
  • Group membership that follows the IdP automatically

๐Ÿ”ฅ Qualities

  • Precise, cautious, audit-minded
  • Will read documentation โ€” and will hold us to it
  • Escalates fast when blocked; measures us on time-to-resolve

๐Ÿ”„ Target flow

Open Settings โ†’ Security
โ†’
Add configuration (SAML or OIDC)
โ†’
Paste IdP metadata / discovery URL
โ†’
Map attributes
โ†’
Test sign-in
โ†’
Enforce SSO org-wide

Bringing SSO to multi-tenant AI Hub

Shipped in Release 1. Enterprise-tier organisations can now configure SAML 2.0 and/or OIDC single sign-on themselves, from Settings โ†’ Security โ€” with multiple configurations per org, mixing protocols.

Before SSO

Before

  • SSO available only to single-tenant customers
  • MT customers given a whole ST environment as a workaround
  • Configuration done by Instabase engineers via environment variables
  • No way to test a configuration without risking lockout

After

  • Self-serve SAML + OIDC config for MT org admins
  • Multiple configurations per organisation, protocols mixed
  • Guided setup that mirrors the admin's own IdP vocabulary
  • Test sign-in first; enforce SSO only once it works

Testing configuration

Flow without test option: user gets locked out in wrong config.

Flow without test option: user gets locked out in wrong config

Flow with test option enabled: Admin has a secure way to correct config again

Flow with test option enabled: Admin has a secure way to correct config again
Speaking every IdP's own vocabulary

Guided setup only works if every field is labelled the way the admin's own IdP labels it. Mapping AI Hub's fields to each provider's own terminology was part of the design work.

Step 1 → paste into IdP)

Our fieldAD FSMicrosoft Entra IDOneLoginAuth0JumpCloudOktaPingFederate
Application labelDisplay nameNameDisplay NameApp nameDisplay LabelApp label/nameConnection Name
Service provider entity IDRelying party identifierIdentifier (Entity ID)Audience (Entity ID)Entity ID / AudienceSP Entity IDAudience URI (SP Entity ID)Entity ID (Partner's Entity ID)
Assertion consumer service URLAssertion Consumer Service (POST) URLReply URL (ACS URL)ACS (Consumer) URLApplication Callback URLACS URLSingle sign-on URLACS URL
Our fieldAD FSMicrosoft Entra IDOneLoginAuth0JumpCloudOktaPingFederate
Redirect URI— (no native OIDC)Redirect URI (Reply URL)Redirect URIAllowed Callback URLsRedirect URIsSign-in redirect URIRedirect URIs
Required scopesRequested/delegated permissionsScopesPermissions/ScopesScopesRequested scopesRequested Scopes

SAML (step 2 → AIhub configuration)

SAML fieldOktaMicrosoft Entra IDPingFederateAuth0JumpCloudOneLoginAD FS
Sign on URLIdentity Provider Single Sign-On URLLogin URLSSO Endpoint (Browser SSO)Sign On URLIDP URLSAML 2.0 Endpoint (HTTP)SAML 2.0/WS-Fed SSO URL
Identity provider entity IDIdentity Provider IssuerAzure AD IdentifierPartner's Entity ID / IssuerIssuerIDP Entity IDIssuer URLIssuer / Entity ID (federation metadata)
X.509 certificateX.509 CertificateCertificate (Base64)Signing CertificateX.509 Signing CertificateIDP CertificateX.509 CertificateToken-signing certificate
OIDC fieldOktaMicrosoft Entra IDPingFederateAuth0JumpCloudOneLoginAD FS
Client IDClient IDApplication (client) IDClient IDClient IDClient IDClient IDClient Identifier
Client SecretClient SecretClient secret (value)Client SecretClient SecretClient SecretClient SecretGenerate shared secret
Discovery URL{domain}/.well-known/openid-configurationlogin.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configurationOIDC Provider Metadata endpoint{domain}/.well-known/openid-configurationDiscovery Document URLWell-Known Config URL/.well-known/openid-configuration (fed metadata)
Authorization endpoint URLAuthorize URLOAuth 2.0 authorization endpointAuthorization EndpointAuthorization URLAuthorization EndpointAuthorization EndpointOAuth2 Authorization Endpoint
Token URLToken URLOAuth 2.0 token endpointToken EndpointToken URLToken EndpointToken EndpointOAuth2 Token Endpoint

Key design decisions

1. Removing "domain verificaation" from SSO configuration entirely

๐Ÿงฉ ProblemThe first design routed users to an IdP by claiming an email domain. Nothing stopped an org admin from claiming a domain they don't own โ€” including gmail.com โ€” and silently intercepting other people's logins. A configuration screen had become a phishing vector.
๐Ÿ”€ Options(a) Keep domains, add a manual security-team approval gate before activation. (b) Keep domains, add DNS-based domain verification. (c) Remove the domain concept entirely and bind SSO configs directly to the organisation.
โœ… DecisionOption (c). SSO configurations are associated with an org; membership is still gated by invitation, so there is nothing to hijack.
๐Ÿ’ก WhyThe approval gate solved the security problem by adding a human bottleneck to a self-serve feature โ€” trading the thing we were shipping for the thing we were preventing. Removing the concept removed the entire attack surface and deleted a field, a validation state, an error state and a support process. The best security fix was less UI, not more.

โš–๏ธ Trade-off: Multi-domain organisations (separate dev / test / prod domains, requested by one large financial-institution customer) are not served at launch. I documented this as an explicit, tracked gap rather than a silent one.

2. "Test connection" instead of a separate mode

๐Ÿงฉ ProblemAn admin cannot know whether their configuration works until a real human tries to log in โ€” and by then, if they have already enforced SSO, everyone is locked out.
๐Ÿ”€ Options(a) A dedicated "test mode" state on the configuration, with its own lifecycle. (b) An inline test action that runs a real sign-in against the saved config.
โœ… DecisionInline test, plus a hard rule in the flow: password sign-in stays on until a successful SSO login is confirmed.
๐Ÿ’ก WhyA separate test mode introduces a third state ("configured but not live") that has to be explained, surfaced in the list, and reasoned about at login-routing time. The inline test gives the same confidence with no new state โ€” the safety net is the password fallback, not a mode.

3. Making the destructive step feel destructive

๐Ÿงฉ ProblemTurning off "Allow sign-in with email and password" is the single action in the product that can lock an entire organisation out of its own account, recoverable only through Instabase Support.
โœ… DecisionTreat it as a separate, deliberate step after successful testing โ€” never bundled into saving a configuration โ€” with an explicit caution about what happens if the config is wrong, and a documented recovery path.
๐Ÿ’ก WhyEnforcement is a policy decision, not a configuration detail. Separating "does this work?" from "is this now mandatory?" is the difference between a confident admin and a support ticket from a locked-out CIO.

4. Attribute mapping designed around its failure mode

๐Ÿงฉ ProblemThe most common real-world failure was an attribute error surfacing at login as a raw string โ€” SAML response is missing uid attribute โ€” to an end user who has no idea what a SAML attribute is, hours after the admin finished configuring.
โœ… DecisionRequired vs optional attributes explicitly separated in the UI and the docs; groups and is_admin presented as optional capabilities with their consequences spelled out; advanced signing settings given clear defaults (assertion signed on, response signing optional, IdP-initiated SSO allowed).
๐Ÿ’ก WhyThree separate customer escalations traced back to attribute confusion. The fix isn't a better error message at login โ€” it's making the requirement unmissable at configuration time.

5. Naming the danger in is_admin

๐Ÿงฉ ProblemIf the IdP sends is_admin, it wins โ€” it overrides any role change an admin makes inside AI Hub, silently, on every single login. An admin could demote someone in the UI and watch it undo itself the next morning.
โœ… DecisionSay it plainly, everywhere the attribute appears: this value overrides manual role changes and resets on every login โ€” keep the number of admins minimal.
๐Ÿ’ก WhyYou cannot design away a protocol behaviour. You can refuse to let it be a surprise.

Track 2 โ€” Access that follows the org chart (RBAC)

IdP group mapping for RBAC - By Admin

SSO answers "can this person log in?". Group mapping answers "and what should they be able to see?". SAML group mapping existed only for single tenants; OIDC group mapping was documented but did not exist โ€” the gap a major customer found before we did.

Before

  • OIDC customers managed every group membership by hand
  • Docs claimed OIDC group mapping worked โ€” it didn't
  • SAML mapping was one IdP group per AI Hub group
  • No signal about when a membership change would take effect

After

  • OIDC group mapping at parity with SAML, same mental model
  • Many external IdP groups can map to one AI Hub group
  • Mapping created inline while creating the group, or added later
  • Sync timing stated explicitly wherever mapping is configured

Key design decisions

1. Many-to-one mapping, not one-to-one

๐Ÿงฉ ProblemReal enterprises don't have one clean group per function. They have eu-analysts, us-analysts and contractor-analysts โ€” all of whom need the same AI Hub workspace access.
โœ… DecisionLet an AI Hub group accept multiple IdP group names, entered as a list. This removed earlier limitation the earlier SAML implementation had carried.
๐Ÿ’ก WhyThe one-to-one constraint was an implementation artefact leaking into the mental model. Modelling the mapping the way customers actually think โ€” "these IdP groups mean this thing here" โ€” removed a whole class of workaround groups.

2. Telling the truth about sync timing

๐Ÿงฉ ProblemGroup membership doesn't sync when the admin saves the mapping. It syncs at each member's next login. So an admin creates a mapping, sees an empty member list, and concludes it's broken. Worse: removing someone from a group in the IdP does not remove their access until they log in again.
โœ… DecisionState it at the moment of the action, & also in empty states, not in a help article: the member list will populate as members log in, and removals apply at next login. Requires SCIM implementation. But started with JIT provisioning due to time constraints.
๐Ÿ’ก WhyThis is the honest version of a security-relevant limitation. An admin who knows about the delay can plan around it; one who doesn't will assume offboarding is instant, which is exactly the assumption an auditor punishes. It also gave the roadmap its clearest argument for SCIM.

3. Handling Existing users groups in org while transistioning to new RBAC

๐Ÿงฉ ProblemWhat happens to the existing members in HI Hub who are alreadying part of a group in AIHUB, and what happend new SAML or OIDC group mapping is added.
โœ… DecisionPreserve the AIhub gorup mapping, and show the memberhip source clearly. Let adming handle removal of AI-Hub group mapping if they want to remove AI hub managed group membership.
๐Ÿ’ก Why Old group mapping still holds value for existing users. in the orgs which are transitining to new RBAC, it allows the admin to keep the existing group membership for existing users.

Iteration of add multiple group for many-to-one mapping

Why: admins have a long list to map initially when they configure any org. Doing it via single addition is cumbersome. Chose the best of each iteration for the final implementation.

Bulk add options

Track 3 โ€” From raw tokens to oauth compliance

Persona: ๐Ÿ‘ฉโ€๐Ÿ’ป Developers / API engineer / Admins

๐Ÿ˜“ Pain points

  • Automation has no identity of its own in an SSO-only org
  • Long-lived tokens violate their own security policy, transition to new Oauth
  • A token silently carries its creator's full admin rights
  • No API to create, rotate or delete tokens programmatically

๐Ÿ”‘ Needs

  • Tokens issued and revoked by their own IdP
  • A non-human account they can map a client to use
  • Explicit, inspectable scope on every token
  • A copy-paste path that actually works first try

๐Ÿ”ฅ Qualities

  • Reads the error body, not the error toast
  • Judges the product by its first successful API call
  • Will happily automate around us if we get in the way

๐Ÿ”„ Target flow

Register app in own IdP
โ†’
Add OAuth provider config in AI Hub
โ†’
Map sub to a service account
โ†’
Request JWT from IdP
โ†’
Call AI Hub API as Bearer
โ†’
Disable native tokens org-wide

OAuth-compliant API authentication

Delivered in two phases: Release 2: making existing AI-hub Oauth app to issue Oauth compliant tokens and depreciation of raw AI-Hub issued tokens. Release 3: let organisations bring their own OAuth provider so their IdP issues the JWTs AI Hub validates, added scopes so a token can carry less authority than the identity behind it.

Before

  • Long-lived opaque tokens, generated in the UI
  • Token silently inherits its owner's full permissions
  • No expiry, no rotation, no IdP-side revocation

Stage 1 solution

  • AIhub Oauth app which issues short lived tokens (15min)
  • Signature, issuer, audience and expiry validated on every call
  • Ability to set scope of the token
  • Depreciation and migration plan of the old AI-Hub raw rokens

Stage 2 solution

  • Customer's own OAuth provider issues short-lived JWTs (15โ€“60 min)
  • Signature, issuer, audience and expiry validated on every call
  • Scope claim downscopes the token to specific roles

Key design decisions

1. Two objects, not one: provider configuration and account mapping

๐Ÿงฉ Problem"Set up OAuth" is really two different jobs done by two different people at two different times: an org-wide trust relationship with an identity provider, and a per-identity claim that "this external subject is that account here".
๐Ÿ”€ Options(a) One combined wizard. (b) Two separate objects, each with its own lifecycle and its own home in the IA.
โœ… DecisionTwo objects. The provider configuration lives under Identity & access; the account mapping lives on the member or service account it belongs to. Both are required before any external token authenticates.
๐Ÿ’ก WhyConfiguring a provider is a one-time act; mapping accounts is continuous, and belongs where the account lives. Splitting them also made the failure states diagnosable โ€” "no provider" and "no mapping" are genuinely different problems with different fixes.

2. Terminology as a design deliverable

๐Ÿงฉ ProblemEarly drafts used "OAuth client" for three different things: the customer's IdP auth server, the app registered inside it, and the link between that app and an AI Hub identity. Reviews kept stalling on which one anyone meant.
โœ… DecisionFix the vocabulary before the UI: OAuth provider configuration (the trust relationship), external OAuth client (the app in the customer's IdP), account mapping (the link to an AI Hub identity).
๐Ÿ’ก WhyIn identity work, the naming is the mental model. Once the three objects had distinct names, the screens, the API and the documentation fell out of it โ€” and the review conversations stopped going in circles.

3. One client, one identity

๐Ÿงฉ ProblemShould several external OAuth apps be allowed to map to a single shared service account? It's convenient โ€” and it destroys least privilege, because every app inherits the same rights.
โœ… DecisionOne-to-one. Each external client maps to exactly one AI Hub user or service account. Each account may hold one mapping per configured provider.
๐Ÿ’ก WhyOne global investment bank customer cannot configure scopes on their side at all. If a customer can't express least privilege through scope, the only remaining lever is the identity itself โ€” so the client had to become the unit of privilege. A constraint from one customer's security policy became the safer default for everyone.

4. Scope may only reduce, never grant

๐Ÿงฉ ProblemIf a JWT's scope claim controls what the token can do, could a customer mint themselves admin rights by writing an admin role into a token?
โœ… DecisionScope always downscopes and never upscopes. It is expressed as immutable role UUIDs; multiple roles are additive (most permissive wins); a workspace role without an organisation role is invalid; and a workspace role still requires real membership of that workspace. If the scope claim is absent or invalid, the token falls back to the mapped account's normal roles.
๐Ÿ’ก WhyThis is the whole reason enterprise security teams accept token-based access. Using role UUIDs instead of readable strings was the less friendly choice for humans โ€” and the right one, because a renamed role must never silently change what a live token can do.

5. A migration path, not a flag day

๐Ÿงฉ ProblemEvery existing customer had working automation built on raw internal tokens. Deprecating them abruptly breaks production pipelines at exactly the customers we're trying to impress.
โœ… DecisionA staged migration: (1) external IdP tokens ship alongside native tokens; (2) admins gain granular control over native token creation โ€” all members, selected groups, or nobody; (3) an org that has moved to OAuth can switch native tokens off entirely, forcing all API access through the provider; (4) AI Hub-managed OAuth2 tokens replace the remaining opaque tokens.
๐Ÿ’ก WhyDeprecation is a design problem, not a release note. Giving each organisation the switch โ€” and a reversible one, since disabling native tokens suspends rather than destroys them โ€” let security-forward customers move immediately without breaking anyone else.

Audit logs of everything

Previously, audit trails were dug out of raw log files by an internal engineer โ€” there was no UI for admins to see them at all. This was a named SOC 2 blocker for several enterprise deals; giving admins a self-serve audit log view unlocked it.

Audit logs

*All are dummy values, just a placeholder

My process

Research โ€” mining the evidence that already existed

I had no budget for a formal study and no access to a bank's IT team on demand. What I did have was three years of Slack: presales questions, Zendesk escalations, engineering threads and customer call notes. Internal engineers support,I treated that as the research corpus.

Systematic Slack & ticket mining

I pulled every message from slcak channels and tickets then coded each reported problem by category, reporter, root cause and resolution status. The result was a 22 distinct issues logged in a status dashboard: 2 open, 5 workaround-only, 4 documentation gaps.

This is what turned a vague "we need SSO" into a prioritised, evidence-backed problem list I could defend in a roadmap review.

Customer validation calls

I joined and read back the notes from validation calls with the accounts driving the work. One global investment bank's constraints reshaped the design more than any internal opinion did: they use the client credentials flow, their sub claim is a random string rather than an email, and their security team cannot configure per-token scopes on their side.

"We can't use long-lived opaque tokens. Our IdP issues the token, or we don't integrate."

โ€” synthesis of the security requirement from that engagement, captured in the call notes

That single constraint is why the final model maps one external OAuth client to exactly one identity โ€” if a customer can't scope a token, the client itself has to be the unit of least privilege.

Primary research โ€” in the users' own words

Hard to get an access to the enterprise customers. Was on presales and support channel calls to get the insights. Below are the quotes from the calls. Including some interviews with internal customer engineers.

๐Ÿšง Theme 1 โ€” "We'll just give them a different environment"

The absence of multi-tenant SSO wasn't costing us features. It was costing us infrastructure, margin and credibility โ€” because the field had invented a workaround and normalised it.

"It has been agreed internally that we will provide them ST instance despite them being a MT customer as a temporary measure to bypass SSO requirement."
Account team โ€” European luxury retail groupWorkaround
What it told me: we were provisioning an entire dedicated environment as a substitute for one settings screen. The cost of the missing feature was being paid in infrastructure, not in the backlog.
"Is SSO available for Commercial (MT) customers or only Enterprise? What security tools exist without SSO โ€” IP whitelisting, password requirements?"
Presales lead, APACDoc gap
What it told me: our own sellers couldn't state our security posture. Entitlement clarity is a design deliverable, not a pricing-page footnote.

๐Ÿ‘ฅ Theme 2 โ€” Nobody could explain how access actually syncs

Group mapping questions were never "how do I create one?". They were always about the invisible rules: is it required, when does it apply, what happens to people already in the group.

Whether group mapping was required, whether groups auto-created themselves, and when membership actually synced were all left to guesswork โ€” the documentation described the mechanism but never the defaults.
Before this shipped
What it told me: three reasonable assumptions, all wrong at once. Mapping is optional, groups are not auto-created, and sync is not immediate โ€” none of it said out loud.
Whether SAML group mapping was even supported wasn't something the team could always confirm without checking with engineering first.
Before this shipped
What it told me: when internal teams have to ask engineering whether a shipped feature exists, the capability story is broken before it ever reaches a customer.

๐Ÿค– Theme 3 โ€” Machines have no identity

The most commercially expensive theme in the log. Every quote here is attached to an enterprise account with a signed contract or an active go-live date.

"[The customer] cannot use long-lived opaque tokens due to internal security policy. Their IdP issues the token, or they don't integrate."
Call notes โ€” global investment bankResolved ยท Release 2
What it told me: this is not a feature request, it's a policy wall. No amount of UX makes a forbidden credential acceptable. Design response: validate JWTs issued by their IdP โ€” we stop being the issuer.
"[They] would not go live without a service account feature. The workaround โ€” create an account with a group email ID โ€” was rejected, since their login is via SSO only."
Presales โ€” global security vendorOpen โ€” go-live blocker
What it told me: we kept conflating login with API access. The answer was never "let a faceless account log in" โ€” it was a non-human identity that never logs in at all.
"As an admin, [we need to] programmatically CREATE / UPDATE / DELETE API tokens to automate provisioning."
Requirements call โ€” European bankWorkaround
What it told me: at enterprise scale, credential management is itself automated. A UI-only token screen isn't a smaller version of the feature โ€” it's the wrong shape entirely.

Competitive analysis

I audited how the intelligent document processing market handles enterprise identity โ€” and then widened it, because in most deals we weren't only being compared to IDP vendors. We were being compared to the IAM model the customer already had from their cloud provider.

Config analysis Sign-in analysis
Product Category position SSO (SAML / OIDC) IdP groups โ†’ roles Machine identity & API auth Audit logs
UiPath
Document Understanding
RPA-led automation suite; IDP as one capability of a large platform SAML 2.0 + OIDC, self-serve in Automation Cloud Directory groups mapped to roles at tenant and folder level First-class: external applications with OAuth client credentials, scoped per app Tenant-level audit trail, exportable
Automation Anywhere
Document Automation
RPA incumbent; document automation bundled into Control Room SAML 2.0 SSO, IdP-driven Role mapping from directory groups API keys plus OAuth-style tokens via Control Room Detailed audit log with filtering
ABBYY
Vantage
OCR/IDP specialist, deep document-engineering heritage SSO via SAML/OIDC on the cloud offering Tenant roles, group-driven assignment OAuth client credentials for API integrations Transaction & admin audit trail
Hyperscience Enterprise-first IDP, heavily deployed in financial services & government SAML SSO standard in enterprise deployments Group โ†’ role mapping API tokens; deployment often self-hosted inside customer perimeter Audit logging positioned as a compliance feature
Rossum Modern cloud-native document AI, developer-friendly SAML/OIDC SSO on enterprise tiers Role assignment, group support API tokens and OAuth-based access for integrations Activity/audit history
Tungsten Automation
(formerly Kofax)
Long-standing capture platform, large regulated install base SSO across the platform suite Directory-integrated RBAC Platform API credentials Compliance-oriented logging
Google Cloud
Document AI
Hyperscaler API; identity inherited from the cloud platform Google Cloud Identity / any IdP federated into it IAM roles and policy bindings, inherited org-wide The bar: native service accounts, short-lived OAuth2 tokens, workload identity federation Cloud Audit Logs โ€” admin, data access, immutable
Microsoft Azure
AI Document Intelligence
Hyperscaler API, default choice inside Microsoft estates Microsoft Entra ID, natively Entra groups โ†’ Azure RBAC roles The bar: managed identities, no secrets to store or rotate Azure Monitor / activity logs
Amazon Web Services
Textract
Hyperscaler API, embedded in AWS-native pipelines IAM Identity Center federated to the customer's IdP IAM roles and permission sets from IdP groups The bar: IAM roles and STS short-lived credentials, no long-lived keys CloudTrail โ€” every API call, immutable

Data as of feb 2026

What the analysis actually changed

๐ŸŽฏ Table stakes, not differentiator

Every serious competitor had SSO and group-driven RBAC. That reframed the pitch internally: this work does not win deals on features โ€” its absence loses them at security review. Which is a far stronger argument for prioritisation than "customers want SSO".

โ˜๏ธ The real benchmark was the hyperscalers

Our buyers already run AWS, Azure or GCP, where machine identity is native: service accounts, short-lived credentials, no long-lived keys. Against that baseline, our long-lived opaque token wasn't behind the IDP market โ€” it was behind the infrastructure customers use every day.

๐Ÿ”‘ Machine identity was the actual gap

The clearest differentiator across the field wasn't login โ€” it was how well non-human access was modelled. That confirmed the OAuth external tokens track deserved equal weight to SSO, rather than being treated as a follow-on.

๐Ÿงญ Self-serve setup was our opening

Several IDP competitors still route enterprise identity setup through support or professional services. Making configuration genuinely self-serve โ€” with a safe test path โ€” was a place we could be visibly better, not merely equal.

๐Ÿ“œ Audit is a sales artefact

The hyperscalers treat audit logging as a headline capability with its own documentation, because compliance teams read it. Ours was a preview feature on one tenancy model โ€” a gap I raised on the roadmap rather than let sit quietly.

๐Ÿšช Nobody wins on the identity screen

No admin picks a document AI platform because of its SSO form. This shaped every interaction decision: the goal is to be finished, correct and forgettable.

Frameworks & knowledge I analysed

I could not design this credibly by reading competitor screenshots. Enterprise identity is governed by published specifications and audited against named control frameworks โ€” so I worked from the primary sources โ€” and turned what I learned into my own working checklists for designing in this domain.

๐Ÿ” Protocol specsDefined what the system must validate on every assertion and token.
๐Ÿ›ก Security & complianceThe language security reviewers and auditors actually use.
๐Ÿ— Product & IdP referencesSource of the enterprise feature ladder and the cross-IdP field naming.
๐Ÿข Internal corpusRead end-to-end to verify what shipped against what was specified.
CE config call logs, pre salse support calls existing docs.instabase.com/admin Slack channels + Zendesk

The checklist I designed against

Specifications tell you what is possible; audits tell you what is required. Neither tells you what to check as a designer. So I reduced everything above into two working checklists of my own โ€” one I run before designing anything in this domain, one I hold the finished design to before I call it done. I still use both.

Pre-design check-list
before I draw a single screen
Framing
Who configures, approves, and is affected?
What does the security reviewer need to see?
Which spec defines the correct behaviour?
What does the customer's own IdP call this?
Which tier or flag gates this capability?
Threat
How would a bad actor abuse this screen?
What is the worst irreversible action here?
Can any input grant more access than it should?
What must never be logged or displayed?
Hidden state
What is invisible to the user right now?
When does this take effect โ€” is that said?
On failure, who sees it, and can they act?
Evaluation check-list
before I call the design done
Clarity
Fields named the way the admin's IdP names them
Required vs optional is unmissable
No protocol jargon in a user-facing error
Safety
Nothing destructive without a deliberate step
A safe way to test before enforcing
Every lockout has a documented way back
Honesty
A gated capability never renders as absence
Sync delays stated at the moment of action
Gaps named, not implied away
Completeness
Empty, loading, error and gated states designed
Least privilege by default, never admin
Docs verified by the engineer who built it

These two lists came out of the 22-issue log and the specifications above โ€” most items exist because something in that log went wrong for a real customer. They travel with me to any product where identity, permissions or credentials are involved.

IdP naming matrix โ€” 8 providers ร— field names ร— where to find each value

Building the IdP field matrix

Every identity provider names the same three fields differently. Entra calls the ACS URL a "Reply URL"; Okta calls it "Single Sign On URL"; AD FS calls it the "Relying Party SAML 2.0 SSO service URL". Admins were transcribing values between two tabs and guessing.

I built the full cross-reference matrix for all 8 supported IdPs and turned it into an in-product content requirement: the configuration UI names the field the way the admin's own IdP names it, not the way the SAML spec does.

Benchmark โ€” what "enterprise-ready" actually means

Before designing screens I wrote down the standard an enterprise security review measures a SaaS product against. This became the scoring sheet the team used to decide what was in scope, what was deferred, and what we were consciously accepting as a gap.

CapabilityWhat enterprises expectAI Hub beforeAfter this projectStatus
SAML 2.0 SSOSelf-serve, per-tenant, multiple configsSingle-tenant onlyMulti- and single-tenant, self-serve UIโœ… Shipped R1
OIDC SSOAuth code flow, discovery URL, claim mappingSingle-tenant onlyMulti- and single-tenant, discovery-URL basedโœ… Shipped R1
RBAC via IdP groupsGroup claims drive product rolesSAML only; manual otherwiseSAML + OIDC group mapping, many-to-oneโœ… Shipped
JIT provisioningAccount created on first SSO loginST onlyAccount auto-created on first SSO login, MT includedโœ… Shipped
API authShort-lived OAuth2 JWTs, IdP-issuedLong-lived opaque tokensExternal IdP JWT validation + native token controlsโœ… Shipped R2
Least privilegeDownscoped tokens, per-client identityToken inherits owner's full rightsScope claim with role UUIDs; scope can only reduceโœ… Shipped R3
Audit logsImmutable, exportable, filterablePartial14 categories, CSV/JSON export, 2-year retention๐ŸŸก Preview, ST only
MFAEnforced by the IdP, signalled via amrPer-account, password logins onlyDelegated to the customer's IdP under SSO๐ŸŸก Entirely IdP managed
SCIM offboardingIdP pushes deactivation in real timeNoneNot built โ€” sync happens at next login๐Ÿ”ด Named gap

Naming the red rows explicitly, This made the matrix usable in sales conversations. Presales could finally answer "do you support X?" without guessing.

Five principles I set before drawing anything

Security UX fails in a specific way: it is usable right up until the moment it silently isn't. These principles were my filter for every decision that followed, and I put them at the top of every review deck.

๐Ÿงญ Speak the admin's IdP, not the spec

Every field label, helper text and error carries the name the admin sees in Okta, Entra or PingFederate. The SAML vocabulary is our problem, not theirs.

๐Ÿงช Never let a config change be a leap of faith

Test before enforce, always. The destructive step โ€” turning off password sign-in โ€” is guarded, explained and reversible for as long as possible.

๐Ÿชž Make the invisible visible

Sync timing, gating flags, entitlement tiers and token permissions are all invisible state. If the user can't see it, they will assume the worst and file a ticket.

๐Ÿ”ป Permissions only ever go down

No mechanism in this system may grant more access than the identity behind it already has. Scope downscopes; it never upscopes.

๐Ÿงฑ Design the threat, not just the flow

Every configuration surface got a "how would a bad actor abuse this?" pass before it got a layout. One of those passes removed a whole feature.

๐Ÿ“ข The documentation is part of the product

Four of our 22 reported problems were pure docs failures. I treated the docs surface as a design deliverable โ€” required/optional attribute tables, per-IdP guidance and accurate capability claims shipped as part of the feature, reviewed by the engineer who wrote the code.

Information architecture of 3 tracks

Three tracks landed in the same settings area over the releases. Without a deliberate structure, AI Hub would have ended up with three unrelated "security" screens built by three different period โ€” which is exactly how enterprise settings usually rot.

IA diagram: settings tree before vs. after, with the three tracks colour-coded

The structure I set

  • SSO Logins โ€” how users get in: password sign-in policy,MFAs..
  • Identity & access โ€” SSO configuration, test mode, OAuth provider configurationsauthorization.
  • Organisation โ†’ Groups What people can reach: groups, group mappings, roles.
  • Organisation โ†’ Service accounts Provider's account mappings live on the account, not in a separate registry.
  • Organisatio โ†’ Manage โ†’ Audit logs โ€” what happened, and what's opt-in. Detailed snapshot.

The rule underneath it: an object lives where the user's mental model puts it, not where the API happens to expose it. Account mappings belong on the account. Group mappings belong on the group.

Solutions are listed in the 3 tracks in the above section

Track 1 โ€” SSO Track 2 โ€” Group mapping Track 3 โ€” OAuth tokens

Usability evaluation

Tested with internal participants who mirror the real personas โ€” solution engineers, support engineers and platform engineers who configure customer IdPs for a living โ€” plus configuration walkthroughs with early customers.

TaskParticipantsSuccess rateMedian timeNotes
Configure SAML SSO end-to-end4 Admin75%6 min
  • 1 participant misread the ACS URL field on first try
  • Metadata upload was preferred over manual entry
  • Test-before-enforce step reduced hesitation to proceed
Configure OIDC SSO end- to-end5 Admin80%4 min
  • Faster than SAML โ€” discovery URL auto-fills most fields
  • 1 participant pasted the wrong URL type (auth vs. discovery)
  • No confusion once the field was auto-validated
Map an IdP group to an AI Hub group6 Admin83%3 min
  • Confusion only on the many-to-one mapping step
  • Sync-timing note prevented "is it broken?" moments
  • Participants expected group auto-creation โ€” it doesn't
  • Quickest task once the mental model clicked
Register an OAuth provider + account mapping4 Engineer50%9 min
  • 2 of 4 needed a hint to find account mapping under the member page
  • Provider config vs. account mapping split wasn't obvious upfront
  • Once found, mapping itself took under a minute
  • Lowest success rate of all five tasks
Make a first successful authenticated API call4 Engineer75%5 min
  • Copy-pasted sample code worked first try for 3 of 4
  • 1 participant hit a scope error, resolved by re-reading the docs
  • Placeholder token in samples caused no confusion

What testing changed

๐Ÿ—ฃ Feedback

"I don't know which of these fields my IdP calls what โ€” I'm guessing." Participants tab-switched constantly and transcribed values by hand.

โœ… Change made

Field labels carry per-IdP naming, and the setup surfaces the exact place in each of the 8 supported IdPs where each value is found.

"Exact IdP field names, and Import and export capablities"

๐Ÿ—ฃ Feedback

"So if I save this, is SSO on now? Am I about to break login for everyone?"

โœ… Change made

Saving a configuration and enforcing SSO became two separate, clearly labelled steps, with the password fallback explicitly held open until a successful test.

๐Ÿ—ฃ Feedback

"I created the mapping but the group is empty โ€” did it fail?"

โœ… Change made

Sync timing stated inline at the moment of creation, so an empty list reads as expected behaviour rather than failure.

"Starting showing the message in confirmation modal and table empty state"

๐Ÿ—ฃ Feedback

"Why can't I just paste the role name into the scope? These UUIDs are unreadable."

โœ… Change made

Kept immutable role UUIDs (renaming a role must never change a live token's power) but shipped a copyable role-to-UUID reference and worked scope examples alongside the field.

Changes based on feedback

๐Ÿ—ฃ Feedback

When existing orgs transition from old to new RBAC, they might miss users in the group mapping. It's very hard to confirm if a user belongs to a specific group.

"We have to open every group and check manually."

โœ… Change made

Created a "verify user" tool inside groups: search for a user and instantly see every group they belong to. It turns a manual, error-prone check into a debugging step.

Verify user

How I used AI in this project

This project had a research corpus no human reads end-to-end: three years of Slack across five channels, customer engineer notes and a documentation site. AI is what made that corpus tractable for one designer โ€” and, separately, what I proposed to make SSO setup easier for the admins themselves.

In my own process

๐Ÿ”Ž Corpus mining & issue coding

I used AI to sweep every message across four Slack channels and extract each distinct user-reported problem โ€” reporter, channel, error string, root cause, status โ€” into a structured log. Twenty-two issues, deduplicated and coded, in a day rather than a fortnight of scrolling.

๐Ÿงฉ Root-cause clustering

Rather than clustering by symptom, I had AI propose groupings by underlying cause, then argued with them. The five clusters that survived became the design principles. AI generated the candidate structure; I made the call on what was actually a design problem versus a support problem.

๐Ÿ“š Protocol literacy, fast

I am a designer, not an identity engineer. I used AI as a tutor on SAML assertions, OIDC discovery, PKCE, JWKS validation, amr claims, JIT vs SCIM โ€” until I could hold my own in an engineering design review and challenge decisions on the merits.

๐Ÿ—‚ Cross-IdP matrix generation

The 8-provider ร— field-name ร— where-to-find-it matrix would have been days of documentation archaeology. AI drafted it from provider documentation; I verified every row against real IdP consoles before it became UI content.

๐Ÿงจ Adversarial design review

I ran each configuration surface through a "how would a bad actor abuse this?" pass with AI as the adversary. The domain-claiming attack โ€” an admin claiming a domain they don't own โ€” is the kind of threat this pass is for, and it ended in removing a field entirely.

โœ๏ธ Error & helper copy drafting

Security copy has to be precise and calm at the same time. I drafted variants with AI, then cut hard for accuracy โ€” every claim about behaviour was checked against the technical design docs before it shipped.

๐Ÿ“Š Competitive & standards benchmarking

The enterprise-readiness matrix โ€” SSO, MFA, JIT, SCIM, RBAC, audit logs, retention, SOC 2 / ISO 27001 / GDPR implications โ€” was assembled with AI, then narrowed to what a security review actually asks for.

๐Ÿงพ Spec & handoff acceleration

Field-level specs, state tables and edge-case lists drafted from my flows, then reviewed against the API specification so design and implementation described the same behaviour in the same words.

โš–๏ธ What I did not delegate

Every architectural call โ€” removing domains, one-to-one client mapping, scope-only-downscopes, staging the token migration โ€” was mine, argued in review with engineering and PM. AI compressed the path to being informed. It did not make the decisions, and I verified anything it produced that touched security behaviour.

Collaboration

Working with engineering (1 Eng lead, 2 frontend developers, 2 backend developer)

The technical design documents were written alongside my flows. I reviewed the API specification, the SSO configuration schema and the token-scope permissions matrix directly, and pushed back at that level โ€” schema decisions like removing the domain field, or using immutable role UUIDs for scope, are design decisions wearing engineering clothes. Frontend built against a mocked API surface while the backend was in flight, so I reviewed real interactive builds weeks earlier than a sequential process would have allowed.

Working with product & presales (partial PM support & presales team)

Presales and support were my highest-signal research channel โ€” they hold the objection list. In return, the benchmark and entitlement tables I produced went straight into their hands, so "do you support X?" stopped being answered from memory.

Working with documentation: (1 Docs lead)

I treated docs as part of the design surface: required vs optional attribute tables, per-IdP setup guidance, and the token scope matrix were all shaped as design deliverables and reviewed by the Docs team who wrote the code. The process change I pushed for: docs accuracy is verified by an implementing engineer before publication, Doc links in description line of each section of the product.

Design sign-off

Every screen was walked through with the implementing engineer against the states list โ€” empty, gated, loading, error, partial, destructive-confirm โ€” before it was called done. For identity features the error and gated states are the product, so they got the same scrutiny as the happy path.

Impact & results

Defining product success metrics

Identity features are not measured by engagement โ€” nobody wants to spend time in an SSO settings screen. I defined success as removed friction and removed risk.

๐Ÿ” SSO adoption

Why: share of eligible enterprise orgs with at least one working SSO configuration โ€” the clearest signal the capability is real, not theoretical.

โฑ Time to first successful SSO login

Why: measures the setup experience end-to-end, across the part of the journey that happens inside the customer's own IdP.

๐ŸŽง Auth support tickets per org

Why: the 22-issue log is the baseline. If the design worked, this number falls even as more orgs onboard.

๐ŸŽŸ Share of API calls on OAuth tokens

Why: the migration metric โ€” how much traffic has moved off long-lived opaque tokens.

๐Ÿง‘โ€๐Ÿ’ผ Manual group edits per org

Why: group mapping should make manual membership management disappear. Falling edits mean access now follows the org chart.

๐Ÿšช Orgs enforcing SSO-only

Why: enforcing SSO means the customer trusts the configuration enough to remove the password fallback โ€” the strongest confidence signal available.

๐Ÿข Deals unblocked

Why: the reason the work existed. Count of opportunities where auth was a named blocker and is no longer.

๐Ÿงฏ Environments avoided

Why: MT customers no longer need a dedicated single-tenant environment purely to get SSO โ€” direct infrastructure and margin saving.

Adoption and retention in the first months after each release

SSO configurations created since Release 1

9 orgs configured SAML or OIDC SSO, with % completing setup without a support ticket.

External OAuth adoption since Release 3

37% of enterprise API traffic now authenticates with IdP-issued JWTs instead of long-lived tokens.

Support load auth-related tickets

60% reduction in auth tickets per onboarded org versus the pre-release baseline of 22 catalogued issues.

Manual group management after group mapping

33% fewer manual membership edits in orgs using IdP group mapping.

Impact on business (enterprise pipeline & cost)

๐Ÿข Enterprise deals
Auth no long a blocker
+9 deals unblocked
๐Ÿ’ฐ ARR influenced
XX M$ to XXX M$
+40%
๐Ÿ–ฅ ST environments avoided
0 workaround instances
ST Infra cost saved
โฑ Initial org setup time
4 Weeks to 5 Days weeks
-87.7%

What shipped when

Below is every feature in the order it actually released, followed by what comes next. The three tracks closed the gap that was losing deals. I documented the remainder as a sequenced roadmap so the gaps stay visible to sales and security alike.

Release 1

SSO for multi- and single-tenant

Self-serve SAML 2.0 and OIDC configuration for enterprise-tier orgs, gated by a per-org feature flag. The release that closed the "give them an ST instance to get SSO" workaround.

Post-Release 1

OIDC group mapping

Brought OIDC to parity with SAML group mapping, with many-to-one IdP-group support. Closed a gap a large financial-institution customer had flagged against inaccurate docs.

Post-Release 1

Just-in-time provisioning for multi-tenant

Multi-tenant still requires an invitation before a user can sign in via SSO. JIT would remove the last manual step from onboarding.

Release 2

AI Hub-managed OAuth2 tokens

Short-lived JWTs and refresh tokens issued by AI Hub itself โ€” so customers without their own IdP get the same security posture as those who do.

Post-Release 2

Deprecation of raw AI Hub-issued tokens

Long-lived opaque tokens retired now that AI Hub-managed OAuth2 tokens cover the customers who lack their own IdP.

Release 3

Customer-IdP-managed API tokens

External OAuth provider configuration, account mappings, and JWT validation โ€” letting a customer's own IdP issue AI Hub API credentials.

Post-Release 3

Token scopes

Downscoping via immutable role UUIDs, so a token can carry less authority than the identity behind it. Completed the least-privilege model one global investment bank's constraints required.

Named gap

SCIM provisioning & offboarding

Today, deprovisioning takes effect at next login. SCIM makes removal real-time โ€” the single largest remaining item on an enterprise security checklist.

Named gap

Self-serve activation & multi-domain SSO

Remove the manual per-org flag entirely, and support organisations that need separate IdP configurations per domain or environment.

Next

AI-assisted configuration

The concept from the previous section: metadata parsing, plain-English validation, attribute-mapping inference and a login-failure debug assistant.

Reflections & learnings

๐Ÿ” The research was already written โ€” nobody had read it

Three years of support threads and call notes contained a fully evidenced problem list. The skill wasn't running new studies; it was recognising an existing corpus as research and having the tools to actually process it.

๐Ÿ—‘ The best security fix removed a field

Domain claiming was solvable with an approval workflow, a verification step and three new states. Deleting the concept solved it completely and made the product simpler. Security UX rewards subtraction more than any other area I've worked in.

๐Ÿง  Fluency is the price of entry

I could not have argued for immutable role UUIDs, or against many-to-one client mapping, without understanding JWT validation properly. Designers working on infrastructure have to earn technical credibility โ€” AI shortened that learning curve dramatically, but didn't remove the obligation.

๐Ÿ“ฃ Honest gaps sell better than vague coverage

Writing "we do not support SCIM" made the rest of the matrix credible. Presales stopped hedging, security reviewers stopped digging, and the roadmap gained its most defensible items.

๐Ÿ•ฐ Invisible state is the real enemy

Nearly every failure here โ€” hidden flags, sync delays, silent attribute errors, tokens inheriting permissions โ€” was invisible state. Most of what I designed was making that state legible at the moment someone acts on it.

๐ŸŽฏ What I'd do differently

I'd design the entitlement and gating experience before the feature, not after the tickets. Half our post-launch support load came from a capability existing but being invisible โ€” a problem that cost far more than the feature work itself and was entirely predictable. I would also have pushed for the docs-accuracy gate at the start of the project rather than after a customer found the discrepancy for us.