An enterprise deal needs SSO and SCIM
A customer will only sign if staff log in through their identity provider and leavers are deprovisioned automatically, and their security team wants evidence it works safely.
Test the SSO, SCIM, OAuth and webhook paths enterprise customers will ask about
Your SSO, SCIM, OAuth and webhook paths become part of each enterprise customer's security boundary. We test who can sign in, what gets provisioned, which scopes are granted, which events are trusted and where data goes.
When teams ask for this
You are publishing an OAuth or marketplace app
Your app is going into a platform marketplace, or other companies will install it into their workspaces with scopes you chose.
Webhooks and sync now move customer data
Events, records or files flow in both directions between your product and customer systems, and some of them change state.
An agency is building the integration for a client
You are delivering a connector, SSO rollout or data sync for a client, and their reviewers want an independent check before it goes live.
What a finding looks like
A synthetic example in the format your report uses: evidence, impact, fix.
A SCIM token issued to one tenant can deactivate users in another tenant
- Asset
- api.example.com: PATCH /scim/v2/Users/{id}
- Caller
- SCIM token issued to Tenant B (synthetic test configuration)
- Standard
- OWASP API1:2023 Broken Object Level Authorization; CWE-639
Impact. An admin of any customer tenant, or anyone holding its SCIM token, can lock out or modify users in other tenants by changing the user ID. User IDs appear in shared links and audit exports.
Fix. Resolve the tenant from the SCIM token and scope every user and group lookup to it. Return 404 for users outside that tenant, add a paired-tenant regression test and review the Groups endpoint for the same pattern.
Evidence · request → response
PATCH /scim/v2/Users/usr_7731 HTTP/1.1 Host: api.example.com Authorization: Bearer [redacted: Tenant B SCIM token] Content-Type: application/scim+json {"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations":[{"op":"replace","path":"active","value":false}]}
HTTP/1.1 200 OK Content-Type: application/scim+json {"id":"usr_7731","userName":"[email protected]", "active":false,"meta":{"resourceType":"User"},"tenant":"tnt_A"}
What we test
Named test areas and checks. The scope record in your proposal confirms which apply to your system.
SSO with SAML and OIDC5 checks
- Signature validation, including unsigned assertions, wrapped elements and stripped signatures
- Issuer, audience, recipient and expiry checks, and per-tenant IdP binding
- Account linking by email claim, and just-in-time provisioning into the right tenant and role
- OIDC state, nonce and PKCE handling, redirect URI validation and token exchange
- Whether password login, recovery and API tokens still bypass enforced SSO
SCIM provisioning5 checks
- SCIM token scope: one token, one tenant, and no reach into other tenants' users or groups
- Deprovisioning: active sessions, API keys and refresh tokens revoked when a user is deactivated
- Group-to-role mapping and whether provisioning can grant admin rights unexpectedly
- Attribute handling: email or username changes that re-link to another account
- Token storage, rotation and display in the admin interface
OAuth apps and scopes5 checks
- Requested scopes against what the integration actually uses
- Authorisation code flow: redirect URI matching, state, PKCE and code reuse
- Token storage, encryption at rest, refresh behaviour and revocation on uninstall
- Consent screens and installation by non-admin users where the platform allows it
- Multi-workspace installs: tokens and data kept separate per customer
Webhooks and event handling5 checks
- Inbound signature verification, timestamp tolerance and replay protection
- Outbound webhook URLs: server-side request forgery to internal addresses
- Events that change state (plan, seats, ownership) and whether the source is trusted
- Retries, ordering and idempotency on consequential events
- Secrets shown or logged in delivery history
API keys and service accounts4 checks
- Key scope, per-tenant binding and least-privilege options
- Creation, rotation, expiry and revocation paths, including by former admins
- Key exposure in URLs, logs, front-end code and support tooling
- Service account permissions compared with what the integration needs
Data sync, imports and marketplace apps5 checks
- Field mapping that writes into records or tenants the user should not reach
- Import and export paths: file handling, injection into downstream systems, CSV formula injection
- What data leaves for the connected system, and whether customers can see and limit it
- Marketplace or embedded app surfaces: iframe embedding, postMessage handling and session reuse
- Behaviour when a connection is paused, revoked or uninstalled
What you receive
Items marked “terms to confirm” are set out in your proposal.
| Deliverable | Status |
|---|---|
| Integration mapEach connection with its identities, scopes, data flows, trust decisions and owner, as tested. | Included |
| Technical findingsEvidence, affected flow, impact, severity rationale and a specific fix for each issue. | Included |
| Coverage recordWhich flows, tenants and configurations were tested, and which were not and why. | Included |
| ReadoutA walkthrough with the engineers who own the integration to agree priorities. | Included |
| Remediation verificationRetesting of agreed findings. Rounds and window are set in the proposal. | Terms to confirm |
| Summary for a customer's reviewerA shareable summary of scope and finding status for an enterprise security team, if included in the proposal. | Terms to confirm |
What we need, and what this is not
What we need from you
- A written scope and signed authorisation from the owner of each system being tested
- A test IdP tenant (or a developer account with your IdP vendor) configured for SSO and SCIM
- At least two customer tenants in your product, each with its own SSO and SCIM configuration
- Developer or sandbox accounts on any platform the OAuth or marketplace app installs into
- Integration documentation: endpoints, scopes requested, webhook event types and signing scheme
- A technical contact who can change integration settings during testing
Not included
- Testing the identity provider, marketplace platform or customer systems themselves, without their owner's permission
- Questionnaire completion or document-only vendor assessments
- General systems-integration delivery or building the connector
- Infrastructure and network testing outside the in-scope integration hosts
- Load and denial-of-service testing of sync or webhook pipelines
How we approach it
How we test
The review starts from the integration map: every connection your product offers, the identity it uses, the scopes it holds, the data it moves and the decisions it trusts. Testing then follows the paths an enterprise customer’s security team will care about, using two or more tenants configured the way real customers would configure them.
The checks draw on public standards so coverage is inspectable:
- OWASP Web Security Testing Guide for authentication, session and authorisation testing
- OWASP API Security Top 10 (2023) for API and object-level failures
- OWASP ASVS 5.0 as a reference for authentication and token controls
- The relevant protocol specifications (SAML 2.0, OpenID Connect, OAuth 2.0, SCIM 2.0) for what correct behaviour looks like
Most integration flaws come from trust decisions: accepting an assertion from the wrong IdP, letting a token reach another tenant, trusting an event because it arrived at the right URL. Those are tested by hand.
What good evidence looks like
Each finding names the flow, the identity or token used, the tenant it belonged to, the request, the response and the boundary it crossed. The synthetic SCIM finding on this page is typical: a token from Tenant B changes a user in Tenant A, and the response shows it.
The coverage record lists which identity providers, platforms, event types and tenants were tested, and which were not. An enterprise reviewer will ask whether deprovisioning was tested with the IdP they use. The record should answer that.
How findings are rated and fixed
Severity reflects what the flaw allows in your product: whose accounts, whose data, which actions. It is written as a rationale, not just a label. A missing webhook signature on a read-only notification is not the same as one on a plan-change event.
Fixes are specific to the flow: where to bind the tenant, which claim to check, which scope to drop. Your engineers or your agency’s team implement them. Verification of agreed findings follows the terms in the proposal.
What this review is not
- Not a certification of your product or of any platform you integrate with.
- Not a test of third-party services you do not own.
- Not a questionnaire service. It produces technical evidence, which can help you answer one.
- Not permanent. New scopes, providers or event types need new testing.
For the wider application, see penetration testing. For fix work, see security engineering. The guide what enterprise reviewers expect from a pentest report covers how the evidence is read.
What shapes the scope
Packages have published starting prices. These factors move a quote up or down.
See pricingNumber of integration types
SSO, SCIM, OAuth, webhooks and sync each need their own test plan.
Identity providers and platforms
Each IdP or marketplace platform you support adds configuration and test accounts.
Tenancy
Per-tenant IdP binding and token separation need paired tenants to test properly.
State-changing events
Webhooks and sync jobs that change plans, roles or ownership need logic testing, not just signature checks.
Environment and access
Sandbox availability on third-party platforms and how fast settings can be changed.
Reporting and verification
Reviewer requirements, retest rounds and any shareable summary.
Buying directly, or through an agency
Buying for your own product
You commission the review of your own product's integration surface, usually ahead of an enterprise deal or a marketplace listing. Findings go to the team that owns identity and integrations, and the summary can support the customer's review.
Buying through an agency
You built or are building the integration for a client, so the client authorises testing and owns the product, while third-party platforms may need their own permission. We agree up front who receives findings, who fixes the connector and how results are shared with the client's reviewers.
Being confirmed
- Delivery model and the named assessment lead (in-house or partner-led)
- Retest rounds and window
- Availability and format of a shareable summary for customer reviewers
- Prices and timelines
How the engagement runs
How we work, step by step- 01Scoping callScope record
- 02Written scope and authorisationSigned authorisation
- 03Access and test accountsAccess checklist
- 04Testing windowCritical-issue escalation
- 05ReportReport and evidence
- 06ReadoutEngineer walkthrough
- 07RetestVerification ledger
Methodology behind this service
- Scoping and authorisationHow an engagement is bounded before the first request is sent: the scope record, roles and accounts, environments, rules of engagement, signed authorisation, evidence handling and the conditions that stop testing.
- Authentication and sessionsHow sign-in, recovery, multi-factor, federated login, sessions and tokens are tested across every entry point, including the mobile API and the legacy endpoint nobody remembers.
- Authorization and tenant isolationHow we test that every role can do only what it should, and that one customer organisation can never reach another's data, using a role matrix and at least two test tenants.
- API testingHow we test REST and GraphQL APIs against their documentation and their real behaviour: authorization per endpoint, data exposure, mass assignment, rate limits and versions.
- Reporting and retestHow findings are evidenced, rated and written up, how the readout works, and how fixes are retested and recorded so a reviewer can see what changed.
Questions about integration security reviews
Is this a vendor questionnaire review?
No. A questionnaire or supplier report can inform scope, but this review tests the integration's actual configuration and behaviour. Document review and technical testing are different activities.
Can you test the identity provider or marketplace platform?
Only with permission from its owner, which platforms rarely give for their core service. The review tests your side of the connection, using sandbox or developer accounts. Untested third-party internals are stated as a limitation.
Do we need a real customer's IdP?
No, and it is better not to use one. A test IdP tenant or developer account with each identity provider you support, configured like a customer's would be, is enough.
Is this part of a normal penetration test?
It can be. If your web application test already includes SSO and API keys, that may be enough. A separate integration review makes sense when SSO, SCIM, OAuth apps and webhooks are the main exposure or the trigger is an enterprise deal.
Will this guarantee the customer approves us?
No. The customer's reviewers set their own requirements. Ask what they expect (scope, recency, report contents) before commissioning, so the review produces evidence they can use.
Can you build or fix the integration?
Fixes can be scoped separately as security engineering work. This review does not include building the connector or general integration delivery.
How is it priced?
By the integration types, identity providers and platforms in scope, tenancy, state-changing events, environment access and reporting needs. The proposal states the fee for the defined scope. Prices are not published yet.
What if we change scopes or add an IdP later?
New permissions, providers or event types change the attack surface and usually need a new scope rather than a routine retest.
Related services
- AI application securityA scoped review and test of AI features in your product: data access, retrieval boundaries, tool and agent permissions, prompt injection resilience and output handling, mapped to OWASP guidance for LLM and agentic applications.
- Penetration testingA scoped, manual assessment of a web application and its APIs: authentication, sessions, authorisation, tenant isolation, business logic, input handling and the API surface, reported with request-level evidence and specific fixes.
- Security engineeringScoped work on how security controls are designed and built, from threat models to root-cause fixes and SOC 2 control support.
Scope your integration security reviews.
Tell us the system and the requirement behind it. You get scoping questions, then a fixed quote.