How do we set up Sourcegraph SSO (SAML/OIDC) and SCIM provisioning with Okta or Entra ID for a 1,000+ developer rollout?

Rolling out Sourcegraph to 1,000+ developers changes the stakes for SSO and SCIM. You’re not just wiring up login; you’re defining how access, roles, and team boundaries will work for humans and AI agents across every repository Sourcegraph can see. If SAML/OIDC or SCIM are misconfigured, you either block engineers and agents from the context they need—or you overexpose code to the wrong people.

In this guide, I’ll walk through a practical, enterprise-ready setup for Sourcegraph SSO (SAML or OIDC) and SCIM provisioning with Okta or Microsoft Entra ID, tuned for a 1,000+ developer rollout.

---

Quick Answer: The best overall choice for large-scale, enterprise SSO and provisioning is Okta with OIDC + SCIM. If your priority is tight integration with the Microsoft ecosystem, Entra ID with OIDC + SCIM is often a stronger fit. For organizations with strict SAML requirements or legacy policies, consider SAML (via Okta or Entra) plus SCIM.

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Okta + OIDC + SCIM	Net-new or flexible orgs standardizing on modern OIDC	Clean OIDC config, strong SCIM support, easy app assignments	Need to align Okta groups with Sourcegraph RBAC model
2	Entra ID + OIDC + SCIM	Microsoft 365 / Azure shops with existing Entra governance	Native fit with Entra groups, Conditional Access, hybrid identities	More moving parts if you still have on-prem AD / ADFS in the mix
3	SAML (Okta or Entra) + SCIM	Orgs with SAML mandated by policy or existing SAML backbone	Works with existing SAML posture, easy to align with legacy patterns	Slightly more complex metadata/claim management than OIDC; more brittle when claims change

Comparison Criteria

We evaluated each option against the following criteria to ensure a fair comparison:

• Scalability and stability at 1,000+ users: How reliably the integration handles org-wide rollouts, frequent team changes, and hybrid environments with GitHub, GitLab, Bitbucket, Gerrit, or Perforce in the mix.
• RBAC and governance alignment: How well SSO and SCIM mirror your existing identity model into Sourcegraph’s Role-based Access Controls (RBAC) and org-level policies.
• Operational simplicity: How easy it is for IAM and platform teams to debug, onboard/offboard users, and evolve the setup without breaking access for developers or coding agents.

---

Detailed Breakdown

1. Okta + OIDC + SCIM (Best overall for modern, large-scale rollouts)

Okta + OIDC + SCIM ranks as the top choice because it balances modern protocol support, strong SCIM implementation, and straightforward app assignments that scale cleanly to 1,000+ developers.

What it does well:

• Clean OIDC flow with strong group/claim control:
  OIDC is usually simpler to debug than SAML in practice. With Okta, you can:

  • Define a dedicated “Sourcegraph” OIDC app.
  • Control which attributes (email, username, groups) are sent as claims.
  • Use Okta groups to drive Sourcegraph role mapping (e.g., admin vs standard user).
  • Rely on Okta as the central identity provider while Sourcegraph enforces RBAC at the code layer.

• SCIM provisioning that tracks your org chart:
  Okta’s SCIM implementation lets you:

  • Automatically create Sourcegraph accounts when users are assigned to the app.
  • Deprovision users when they’re removed or leave the company.
  • Sync key attributes (email, display name, perhaps a department/team tag) that you can use for audits and access reviews.
  • Keep humans and AI agents aligned with the same access model, since Sourcegraph uses the same RBAC and identity data for both.

Tradeoffs & Limitations:

• Group sprawl vs Sourcegraph RBAC:
  If your Okta groups are noisy (projects, Slack channels, temporary squads), you’ll want a curated subset to map into Sourcegraph. Otherwise:
  • You risk complex role-mapping logic that’s hard to debug.
  • Group changes in Okta might unintentionally flip roles in Sourcegraph. A “Sourcegraph-*” naming convention for groups and a small set of roles (admin, power-user, standard) keeps this manageable.

Decision Trigger: Choose Okta + OIDC + SCIM if you want a modern, low-friction setup, can standardize on a clean group model for RBAC, and need SSO + lifecycle management that just works as you scale from 100 to 1,000+ developers.

---

2. Entra ID + OIDC + SCIM (Best for Microsoft-centric enterprises)

Entra ID + OIDC + SCIM is the strongest fit if your organization is deeply invested in Microsoft 365, Azure AD (now Entra ID), and Conditional Access policies.

What it does well:

• Tight integration with Entra groups and Conditional Access:
  With Entra ID:

  • You can define a “Sourcegraph” enterprise app that uses OIDC.
  • Map Entra security groups or M365 groups to Sourcegraph roles.
  • Apply Conditional Access (MFA, device compliance, network conditions) specifically to Sourcegraph without disrupting other apps.
  • Align access with the same policies you use for other sensitive internal tools.

• SCIM and hybrid identity support:
  For enterprises synced from on-prem AD:

  • Entra can push SCIM-based provisioning to Sourcegraph, creating and updating users as they appear in your Entra tenant.
  • Offboarding in AD → sync to Entra → SCIM deprovision in Sourcegraph, keeping your code understanding platform aligned with HR and IT.
  • This is especially useful when Sourcegraph is indexing code from GitHub, GitLab, Bitbucket, Gerrit, and Perforce; access is still anchored in Entra, not the individual code hosts.

Tradeoffs & Limitations:

• Complexity in hybrid and legacy setups:
  If you still have ADFS or multiple Entra tenants:
  • You may need additional planning for where the “source of truth” lives for user attributes and groups.
  • Claim rules and Conditional Access policies can be a source of subtle login failures if not tested thoroughly. It’s worth setting up a staging Sourcegraph instance or test app in Entra to shake out misconfigurations before the 1,000+ developer rollout.

Decision Trigger: Choose Entra ID + OIDC + SCIM if your identity and compliance stack is already centered on Entra, you want to apply the same Conditional Access policies to Sourcegraph, and you’re comfortable managing hybrid AD/Entra complexity.

---

3. SAML (Okta or Entra) + SCIM (Best for SAML-mandated environments)

SAML (via Okta or Entra) plus SCIM stands out for organizations where SAML is mandated—either by policy, existing security reviews, or legacy architectural decisions.

What it does well:

• Fits regulated, SAML-first security posture:
  If your security program:

  • Standardizes on SAML assertions for all internal apps, and
  • Already has well-defined attribute/claim mapping patterns, then adding Sourcegraph as a SAML service provider can be straightforward. You reuse:
  • Existing attribute bundles (email, UPN, groups).
  • Existing sign-on policies and MFA flows.

• SCIM keeps lifecycle management modern:
  Even in SAML environments, SCIM:

  • Automates account creation and deprovisioning in Sourcegraph.
  • Keeps Sourcegraph user records aligned to group changes, role changes, and org restructures.
  • Reduces manual admin work, which is critical once you pass a few hundred users.

Tradeoffs & Limitations:

• More brittle metadata and claim management than OIDC:
  SAML setups often struggle when:
  • Certificates rotate unexpectedly.
  • Attribute names change or are repurposed.
  • You introduce new IdPs or consolidate tenants. Debugging is also more opaque compared to OIDC. This is manageable with good documentation and a test app, but it’s a tradeoff to plan for.

Decision Trigger: Choose SAML + SCIM if your security architecture or auditors require SAML for major internal apps, you already have mature SAML patterns, and you’re willing to invest in slightly heavier configuration and change management.

---

Comparison Criteria in Practice: How to Think About SSO + SCIM for Sourcegraph

When you’re connecting Sourcegraph to Okta or Entra for 1,000+ developers, it’s useful to think concretely in terms of:

• Scalability and stability:

  • Can SSO and SCIM survive org-wide directory cleanups, mergers, or tenant consolidations without breaking Deep Search and Code Search access?
  • Are you comfortable rotating certificates, client secrets, or Conditional Access policies without a broad outage?

• RBAC and governance alignment:

  • Do your IdP groups map cleanly to Sourcegraph’s RBAC roles and org-level access patterns?
  • Can you ensure coding agents in Sourcegraph only see what their human owner could see, given the same RBAC and identity rules?

• Operational simplicity:

  • How easily can IAM engineers debug login failures?
  • How clearly can you explain the access model to security reviewers?
  • Are on-call engineers for the platform team confident they can restore access if the IdP changes?

In large enterprises, the “best” protocol is usually the one that mirrors how your identity team already runs most mission-critical apps, with as few one-off exceptions as possible.

---

Step-by-Step: Implementing SSO and SCIM for Sourcegraph with Okta

Below is a high-level, pragmatic flow I’ve used in regulated environments. Adjust specifics based on your security policies and Sourcegraph deployment model (self-hosted vs managed).

1. Design the access model before touching the IdP

• Decide:
  • Who should be a Sourcegraph admin? (Small, trusted group)
  • Who gets standard user access? (Most developers and engineering managers)
  • Do you need a read-only or limited role for auditors or contractors?
• Map these to Okta groups:
  • sourcegraph-admins
  • sourcegraph-users
  • sourcegraph-readonly (optional)
• Decide whether AI agents will act under user identities or service accounts, and ensure those accounts follow the same group/RBAC model.

2. Create the Sourcegraph OIDC app in Okta

• In Okta Admin:
  1. Create a new OIDC application.
  2. Set the application type to Web.
  3. Configure the redirect URI to the URL provided by your Sourcegraph instance (e.g., https://sourcegraph.company.com/.auth/callback or similar, per the Sourcegraph docs).
  4. Restrict assignments to the defined Sourcegraph groups.
• Configure claims:
  • sub / preferred_username → Sourcegraph username or email.
  • email → primary email.
  • groups → include sourcegraph-* groups (using a group filter to avoid sending everything).

3. Configure SSO in Sourcegraph

• In the Sourcegraph site admin UI:
  • Navigate to authentication settings.
  • Add or edit the OIDC provider with the Okta details:
    • Issuer URL.
    • Client ID and client secret.
    • Claim mappings for username, email, and groups.
• Enforce SSO:
  • Disable local signups once you’re comfortable.
  • Keep one emergency admin account (with careful controls) until the rollout is stable.

4. Set up SCIM provisioning in Okta

• In the Okta Sourcegraph app:
  • Enable SCIM provisioning (using the SCIM endpoint and token provided by Sourcegraph).
  • Configure:
    • Create users on assignment.
    • Deactivate users on unassignment.
    • Update user attributes regularly.
• Test:
  • Assign a test user to the app and confirm:
    • SCIM created the user in Sourcegraph.
    • SSO login works.
    • Group-based RBAC is correct.
  • Remove assignment and confirm the user is deprovisioned from Sourcegraph.

5. Pilot with a small cohort before going to 1,000+ developers

• Start with:
  • Platform / developer productivity team.
  • A few engineering squads across different business units.
• Validate:
  • Login behavior for employees, contractors, and shared accounts (if used).
  • Group-to-role mapping, especially admin access.
  • Deep Search and Code Search access respects your repo-level permissions for GitHub, GitLab, Bitbucket, Gerrit, and Perforce.
• Only after the pilot:
  • Roll out assignments to the sourcegraph-users group.
  • Communicate clear onboarding instructions.

---

Step-by-Step: Implementing SSO and SCIM for Sourcegraph with Entra ID

The flows are similar to Okta, but aligned with Microsoft’s terminology and controls.

1. Align Entra groups with Sourcegraph roles

• Create Entra security groups:
  • sg-sourcegraph-admins
  • sg-sourcegraph-users
  • sg-sourcegraph-readonly (optional)
• Decide:
  • Which Azure AD/Entra groups will be eligible for Sourcegraph.
  • Whether to include dynamic groups for specific departments or environments (e.g., sg-sourcegraph-contractors with constrained access).

2. Register the Sourcegraph app in Entra with OIDC

• In Entra ID:
  1. Register a new application for Sourcegraph.
  2. Configure the redirect URI using the URL from your Sourcegraph instance.
  3. Enable “ID tokens” (and access tokens if required).
• Expose user attributes and groups:
  • Enable group overage handling if you have large groups (you may use group IDs instead of names).
  • Configure optional claims (e.g., email, upn, groups) in the ID token.

3. Configure Sourcegraph to trust Entra ID

• In Sourcegraph site admin:
  • Add an OIDC provider with:
    • Entra tenant issuer URL.
    • Client ID and secret from the app registration.
    • Claim mappings for email, username, and groups.
• Confirm:
  • A test user in sg-sourcegraph-users can sign in via Entra.
  • Group membership drives the right Sourcegraph role.

4. Enable SCIM provisioning from Entra to Sourcegraph

• In Entra:
  • Open the Sourcegraph enterprise app.
  • Go to “Provisioning”.
  • Configure the SCIM endpoint and secret from Sourcegraph.
  • Enable automatic provisioning and set sync interval (if configurable).
• Test SCIM:
  • Add a test user to sg-sourcegraph-users and assign the app.
  • Verify the user appears in Sourcegraph.
  • Remove the user and validate they’re deprovisioned.

5. Layer on Conditional Access and governance

• Attach Conditional Access policies to the Sourcegraph app:
  • Require MFA.
  • Restrict access from unmanaged devices if necessary.
  • Limit access by location or network where required by policy.
• Confirm:
  • Deep Search, Code Search, Batch Changes, Monitors, and Insights all respect the enforced identity and device posture.
  • “Zero data retention” for LLM inference in Sourcegraph aligns with your AI and data governance standards.

---

SAML-Specific Considerations for Okta or Entra

If you must use SAML:

• Create a SAML app (Okta) or enterprise application (Entra) for Sourcegraph.
• Exchange metadata:
  • Download IdP metadata and configure it in Sourcegraph.
  • Use the Sourcegraph SP metadata to configure the IdP.
• Map attributes:
  • NameID → username or email.
  • Additional attributes for email and groups.
• Keep an eye on:
  • Certificate expiration dates and renewal plans.
  • Any changes to attribute/claim names—these often cause production outages if not synchronized with Sourcegraph config.
• Still pair SAML with SCIM:
  • SSO handles authentication.
  • SCIM handles lifecycle and attribute sync. Together they give you robust, auditable access control across thousands of developers.

---

Governance, Security, and AI Considerations

When you’re rolling out Sourcegraph as a code understanding platform for 1,000+ developers and coding agents, SSO and SCIM aren’t just checkboxes—they’re the guardrails for:

• Enterprise compliance:

  • Sourcegraph supports SSO with SAML, OpenID Connect, and OAuth, plus SCIM user management and fine-grained RBAC.
  • It’s built with SOC2 Type II + ISO27001 Compliance in mind.
  • LLM inference has Zero data retention beyond what’s required and is never shared with third parties.

• Agent-safe access:

  • Coding agents in Sourcegraph are only as trustworthy as the identity and RBAC model you give them.
  • Ensuring SSO + SCIM are correctly wired means agents operate under the same access constraints as their human owners.
  • Every Deep Search answer and Batch Changes run is grounded in code that your policies allow them to see.

• Operational control:

  • SSO and SCIM make it easy to onboard teams in bulk, run pilots, and expand to new business units without new manual permission workflows.
  • RBAC aligned with IdP groups keeps your security and platform teams in sync.

---

Final Verdict

For most organizations asking “how do we set up Sourcegraph SSO (SAML/OIDC) and SCIM provisioning with Okta or Entra ID for a 1,000+ developer rollout,” the best answer is to:

• Use OIDC + SCIM with your primary IdP (Okta or Entra).
• Mirror a small, well-defined set of groups into Sourcegraph RBAC.
• Pilot with a contained cohort before flipping access for 1,000+ engineers and agents.
• Keep SAML in reserve for environments where policy or legacy architecture demands it.

This gives you a scalable, debuggable identity backbone that matches how your engineers and agents actually work: searching, understanding, and automating changes across 100 or 1M repositories, across GitHub, GitLab, Bitbucket, Gerrit, and Perforce.

Next Step

Get Started