Identity is the single boring procurement question that kills more AI deals than any feature gap. Your vendor's "SSO support" notice on their pricing page survives until your CISO asks for the SAML metadata URL and learns they only support Google OAuth. This piece is the checklist to put on every AI vendor evaluation, with the answers they should be giving you.
SSO — what to require.
1. Which protocols?
Insist on at least one of SAML 2.0 or OIDC. "Sign in with Google" is not SSO for enterprise purposes — it doesn't authenticate against your directory, it authenticates against an external IdP. If the vendor only offers OAuth against Google or Microsoft personal accounts, walk.
2. Service-provider-initiated flow?
Your users start at the vendor's dashboard, type their email, and the vendor redirects to your IdP. This is the flow your users will actually hit; without it they have to remember a separate vendor URL and you can't enforce IdP-side conditional access policies. Ask for the service-provider URL that initiates the flow.
3. Identity provider lookup mechanism.
How does the vendor know which IdP to redirect to? The two acceptable
answers are email-domain mapping (everyone at
acme.com goes to Acme's Okta) or
tenant-subdomain routing. If the vendor says "we use a
global SSO button", that's an OAuth login — not enterprise SSO.
4. Audience and nonce binding (OIDC).
For OIDC, the vendor must verify aud matches their
client_id, iss matches the configured issuer, and (in
authorisation-code flow) the nonce in the ID token matches
the nonce they sent in the auth request. Ask "do you verify all three?"
— vendors who hesitate are doing one or none.
5. Signature validation (SAML).
The SAML assertion is signed by your IdP with a certificate the vendor must validate. Ask which library does this, whether the vendor pins to a specific certificate or trusts the IdP metadata endpoint, and how certificate rotation works.
6. Just-in-time provisioning vs SCIM.
A first-time SSO user lands in the vendor with no account. The vendor either (a) auto-creates the user on first login (JIT) or (b) requires the user to be pre-provisioned via SCIM. JIT is convenient but tells you nothing about whether SCIM works. Test both.
7. Role mapping.
What role does a JIT-created user get? "Member" by default is
acceptable. "Admin" by default would fail any security review. Ask
which role attribute the vendor reads from your IdP's SAML/OIDC
assertion and how you map a SCIM roles attribute to
a tenant role.
SCIM — what to require.
1. SCIM 2.0, not 1.1.
Don't accept SCIM 1.1 — Okta and Azure AD both treat it as legacy.
The discovery endpoint at /scim/v2/ServiceProviderConfig
is the test: it should return the SCIM 2.0 schemas list.
2. Operations the vendor must implement.
| Operation | Used by | Vendor must support? |
|---|---|---|
| GET /Users?filter=… | Okta, Azure AD reconcile | Yes |
| POST /Users | Provision new user | Yes |
| PUT /Users/{id} | Okta updates | Yes |
| PATCH /Users/{id} | Azure de-provision (active=false) | Yes |
| DELETE /Users/{id} | Hard de-provision | Yes |
3. externalId mapping.
The IdP supplies an externalId on create. The vendor
must persist this and use it to look up the user on subsequent
updates — otherwise a user who changes their email becomes
unmanageable from the IdP side.
4. Filter support.
Minimum: userName eq "..." and
externalId eq "...". Okta and Azure AD use both during
reconciliation. Vendors who don't implement the filter
query parameter make IdP-side performance terrible at scale.
5. Bearer-token scoping.
The IdP authenticates with a bearer token issued by the vendor. Ask:
is the token tenant-scoped? A token that gives the
bearer cross-tenant reach is a security incident waiting to happen.
The correct implementation looks up the token, resolves the
tenant_id from the credential row, and only ever
addresses that tenant.
6. De-provisioning semantics.
When the IdP sends active=false on a user, what happens?
Acceptable answers: the user loses tenant membership and can no
longer sign in. Unacceptable: the user is hard-deleted (their audit
trail goes with them). The receipt history must survive
de-provisioning.
What our SCIM + SSO looks like.
Agent Audit ships both today. SCIM 2.0 at
/scim/v2/...: tenant-scoped bearer token (created in
the dashboard, shown once); GET/POST/PUT/PATCH/DELETE; userName
and externalId filters; soft de-provision (membership removed,
receipts preserved); Okta and Azure AD tested.
SSO at /api/auth/sso/start: email-domain lookup picks
the provider; OIDC with audience + nonce binding, SAML with
assertion acceptance (full signature verification ships Q4 2026
and is currently marked as such on the dashboard). One provider
per email domain per tenant, default role configurable per provider.
Both surfaces sit on the operator dashboard at Settings → Identity. You'll know it works because a procurement reviewer doesn't ask a follow-up.