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

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

12 min read

Rolling out Sourcegraph to 1,000+ developers without SSO and SCIM is asking for pain. You’ll end up hand‑managing accounts, chasing down access issues, and trying to retrofit RBAC after the fact. The right sequencing is the opposite: lock in SSO (SAML or OIDC), wire up SCIM provisioning, validate your RBAC model, then open the floodgates.

Below is the rollout pattern I recommend when connecting Sourcegraph to Okta or Entra ID (Azure AD) in a large enterprise.

Rollout strategy for 1,000+ developers

Before touching SAML/OIDC configs, you want three things defined:

  1. Identity source of truth: Okta or Entra ID is the canonical source for users, groups, and roles. Sourcegraph should consume that, not reinvent it.
  2. Access model: Decide which identity groups map to Sourcegraph roles (admin, editor, read‑only, security, etc.).
  3. Environment strategy: Set up and test SSO + SCIM in a staging Sourcegraph instance before production.

At 1,000+ developers, this is not “nice to have.” It’s how you avoid:

  • Orphaned accounts from attrition
  • Teams sharing admin credentials
  • AI features accessible to identities that shouldn’t see certain repos
  • Last‑minute surprises from security review

The rest of this guide covers:

  • Choosing SAML vs OIDC for Sourcegraph
  • High‑level architecture with Okta and Entra ID
  • Step‑by‑step SSO setup (SAML/OIDC)
  • Step‑by‑step SCIM provisioning
  • RBAC and group mapping patterns that scale
  • Testing, cutover, and rollback planning

SAML vs OIDC for Sourcegraph in Okta/Entra ID

Sourcegraph supports enterprise Single Sign On with:

  • SAML
  • OpenID Connect (OIDC)
  • OAuth flows

In practice for Okta/Entra ID:

  • Use OIDC if your organization prefers modern OAuth/OIDC flows and you already run OIDC for other apps. It’s easier to work with in automation and typically has smoother refresh/token handling.
  • Use SAML if your security team has a hard requirement for SAML‑based SSO or you want to reuse existing SAML app profiles.

For a 1,000+ developer rollout, both are viable. The key is consistency with the rest of your portfolio so security and identity teams can support it without special handling.

Architecture overview: Sourcegraph + Okta/Entra ID

At a high level, you’re wiring Sourcegraph into:

  • SSO authentication (SAML or OIDC)
    • Who are you? Are you allowed to log in?
  • SCIM provisioning
    • Create, update, and deactivate Sourcegraph users based on directory data.
  • RBAC & group mapping
    • What are you allowed to see and do once you’re in?

In an enterprise deployment:

  • Sourcegraph sits as a code understanding platform across GitHub, GitLab, Bitbucket, Gerrit, Perforce, and more.
  • Okta or Entra ID provides centralized auth with SAML/OIDC and SCIM.
  • Sourcegraph enforces fine‑grained Role‑Based Access Controls (RBAC) and aligns with your identity groups.
  • Your LLM inference data is not stored beyond what’s required and never shared with third parties, which matters when you start using Deep Search and agents with your org’s code.

Prerequisites and preparation

Before you configure SSO or SCIM, align with these teams and details:

1. Involve the right stakeholders

Bring in:

  • Identity team (Okta or Entra ID owners)
  • Security / governance
  • Sourcegraph admin(s)
  • A representative set of engineering leads (for testing and group design)

2. Confirm Sourcegraph deployment details

Make sure you know:

  • Base URL of your Sourcegraph instance (e.g., https://sourcegraph.company.com)
  • TLS / certificates: The URL must be accessible over HTTPS from users and from Okta/Entra ID
  • Admin access to configure auth providers and SCIM
  • Whether you’re setting this up in staging or production (start in staging)

3. Decide your RBAC and group model

At this scale, define:

  • Which IdP groups will map to:
    • Sourcegraph site admins
    • Sourcegraph power users (Batch Changes maintainers, security leads)
    • General engineering access
    • Limited scopes (e.g., contractors, partner teams)
  • Whether access to sensitive repos (e.g., security, M&A, compliance) will be controlled via:
    • Code host permissions only, or
    • Combination of code host and Sourcegraph RBAC (e.g., groups that can see specific code hosts or repositories)

Decisions here influence what attributes you include in SAML assertions or OIDC claims and which groups you sync via SCIM.

Step‑by‑step: SAML SSO with Okta

This is a common route when your organization standardizes on SAML for web apps.

1. Create a SAML app in Okta

  1. In Okta Admin, go to Applications → Applications → Create App Integration.
  2. Choose:
    • Sign‑in method: SAML 2.0
  3. App name: e.g., Sourcegraph (SAML)
  4. Upload an icon if you want a polished experience in the Okta app launcher.

2. Configure SAML settings

In the SAML configuration:

  • Single sign on URL (ACS URL):
    https://sourcegraph.company.com/.auth/saml/callback
  • Audience URI (SP Entity ID):
    Typically https://sourcegraph.company.com (or a specific Entity ID from your Sourcegraph config).
  • Name ID format:
    EmailAddress (commonly used; confirm with your Sourcegraph config).
  • Application username:
    Email is usually best.

Attribute statements (example):

NameName formatValue
emailUnspecifieduser.email
nameUnspecifieduser.firstName + " " + user.lastName
preferred_usernameUnspecifieduser.login or user.email
groupsUnspecifiedRegex filter on groups

For large orgs, use a group filter instead of sending every group in the IdP:

  • Example Okta filter: only send groups with prefix sg- or in a specific group list.
  • These groups later map to Sourcegraph roles or permissions.

3. Download SAML metadata

Once the app is created:

  • Download the Okta SAML metadata XML.
  • Note:
    • Issuer (IdP Entity ID)
    • SSO URL
    • Certificate (X.509)

You’ll configure these in Sourcegraph.

4. Configure SAML in Sourcegraph

In Sourcegraph’s site configuration (or admin UI for auth providers), add a SAML auth provider block referencing the Okta values. A typical structure includes:

  • IdP issuer (Entity ID)
  • Single sign‑on URL
  • X.509 certificate
  • Claim mappings for:
    • Email
    • Username
    • Display name
    • Groups

Then:

  1. Enable the SAML auth provider.
  2. Disable local sign‑up if required by security policy (after you confirm SSO works and have a fallback admin).
  3. Save configuration and restart/apply if your deployment model requires it.

5. Test SAML SSO

Before opening to 1,000+ devs:

  1. Assign the Okta app to a small test group.
  2. Log into Sourcegraph with:
    • Existing account linked to the same email → confirm it links automatically.
    • New user → confirm auto‑provisioning (if enabled) and correct default role.
  3. Verify:
    • Group claims are present on the Sourcegraph side.
    • Users land on Sourcegraph home with full Code Search access across your connected hosts.
    • Deep Search and agents respect the same permissions model.

Have a backdoor admin account (local auth or separate IdP group) in case SSO misconfiguration locks everybody out.

Step‑by‑step: OIDC SSO with Okta

If you prefer OIDC:

1. Create OIDC app in Okta

  1. In Okta Admin → Applications → Create App Integration.
  2. Sign‑in method: OIDC – OpenID Connect
  3. Application type: Web

Set:

  • Redirect URIs, e.g.:
    https://sourcegraph.company.com/.auth/oidc/callback
  • Post logout redirect URIs if applicable.

2. Configure OIDC settings

Note the produced values:

  • Client ID
  • Client Secret
  • Issuer URL (e.g., https://company.okta.com/oauth2/default)

Configure claims:

  • sub as unique identifier
  • email, name, preferred_username
  • Optional: custom claim for groups (or rely on the /userinfo endpoint if permitted)

3. Configure OIDC in Sourcegraph

In Sourcegraph site config:

  • Set OIDC provider with:
    • Issuer URL
    • Client ID
    • Client secret
    • Redirect URI (must match Okta config)
  • Map claims to Sourcegraph fields:
    • email
    • username
    • Display name
    • Groups (if included as claims)

Then repeat the same small‑group testing process as for SAML.

Step‑by‑step: SSO with Entra ID (Azure AD)

The flow is similar, with Entra’s terminology:

1. Decide SAML vs OIDC

  • SAML enterprise app for traditional SAML flows.
  • App registration + Enterprise app for OIDC.

2. For SAML with Entra ID

  1. Go to Entra ID → Enterprise applications → New application → Create your own application.

  2. Select Integrate any other application you don’t find in the gallery (Non‑gallery).

  3. Choose Set up single sign on → SAML.

  4. Set:

    • Identifier (Entity ID): https://sourcegraph.company.com
    • Reply URL (ACS): https://sourcegraph.company.com/.auth/saml/callback
    • Sign‑on URL: optional but recommended: https://sourcegraph.company.com

  5. Configure User Attributes & Claims:

    • user.mail as email
    • user.userprincipalname or user.mail as NameID
    • Add groups claim with security group filtering or group ID mapping.

  6. Download the Federation Metadata XML and use it in Sourcegraph’s SAML config (same as Okta: issuer, SSO URL, certificate).

3. For OIDC with Entra ID

  1. Go to App registrations → New registration.

  2. Set:

    • Name: Sourcegraph (OIDC)
    • Redirect URI (web): https://sourcegraph.company.com/.auth/oidc/callback

  3. After registration:

    • Note Application (client) ID
    • Note Directory (tenant) ID
    • Under Certificates & secrets, create a client secret.
    • Use the Issuer URL format: https://login.microsoftonline.com/{tenant-id}/v2.0

  4. Configure Sourcegraph OIDC provider with these values and map claims similarly.

Again, test with a pilot group before broad rollout.

Step‑by‑step: SCIM provisioning with Okta

SCIM is how you avoid manual user management at 1,000+ developers. The pattern:

  • IdP is source of truth for create/update/deactivate events.
  • Sourcegraph receives SCIM pushes and aligns accounts accordingly.

1. Enable SCIM in your Sourcegraph instance

In Sourcegraph:

  • Create or obtain a SCIM bearer token.
  • Confirm the SCIM base URL, typically something like:
    https://sourcegraph.company.com/.scim/v2/
    (Exact path may vary by version; follow Sourcegraph’s SCIM docs for your release.)

Keep the token secure; this is your provisioning credential.

2. Configure SCIM in Okta

In the Okta app you created for Sourcegraph:

  1. Go to Provisioning tab.
  2. Under Integration, click Configure API Integration.
  3. Check Enable API integration.
  4. Provide:
    • Base URL: Sourcegraph SCIM endpoint.
    • API Token: SCIM bearer token from Sourcegraph.
  5. Save and test the connection.

3. Define user provisioning rules

Configure:

  • Create users: Enabled
  • Update user attributes: Enabled
  • Deactivate users: Enabled

Map attributes:

  • Okta user.firstName → Sourcegraph givenName
  • Okta user.lastName → Sourcegraph familyName
  • Okta user.email → Sourcegraph email
  • Username mapping aligned with SSO (email is simplest).

4. Group‑based provisioning

At 1,000+ devs, you want access driven by group assignment, not manual app assignment.

  • Create Entra/Okta groups like:
    • sg-all-developers
    • sg-admins
    • sg-security
    • sg-readonly
  • Assign these groups to the Sourcegraph app.
  • Configure Okta to push these groups via SCIM if you’re using Sourcegraph group mapping.

This gives you a single place to grant or revoke access across the entire engineering org.

5. Test SCIM flows

Test with a few users:

  • Add a user to the Sourcegraph group in Okta:
    • Verify a corresponding Sourcegraph account is created.
  • Update user attributes (name, department):
    • Confirm updates propagate to Sourcegraph.
  • Deactivate user in Okta:
    • Confirm Sourcegraph account is deactivated or blocked, based on your policy.

Step‑by‑step: SCIM provisioning with Entra ID

Entra ID’s SCIM integration follows the same logic.

1. Create an Enterprise app for SCIM

If your SSO app supports provisioning, use that. Otherwise, create or enable Provisioning on your existing Enterprise app.

2. Configure the SCIM endpoint

Under Provisioning:

  1. Set Provisioning Mode: Automatic.
  2. Provide:
    • Tenant URL: Sourcegraph SCIM base URL.
    • Secret Token: Sourcegraph SCIM token.
  3. Test connection to ensure Entra ID can reach Sourcegraph.

3. Attribute mappings

Map Entra attributes to Sourcegraph fields:

  • userPrincipalName or mail → username/email
  • givenName, surname, mail, etc.

4. Scope and groups

Under Provisioning → Settings → Scope:

  • Start with Sync only assigned users and groups.
  • Assign:
    • sg-all-developers
    • sg-admins
    • Other relevant groups

Run the provisioning job and confirm:

  • Users appear in Sourcegraph.
  • Group memberships map as expected (if using groups for RBAC).

RBAC and group mapping patterns that scale

Once SSO and SCIM are in place, the next question is: who gets what level of power?

For a large org:

  • Use IdP groups as the single source of truth for roles.
  • Map groups to Sourcegraph roles and capabilities.

Common pattern:

  • sg-admins → Sourcegraph site admins
  • sg-batch-maintainers → Elevated permissions for Batch Changes
  • sg-security → Access to Code Search, Deep Search, Monitors and security‑sensitive queries
  • sg-all-developers → Baseline developer access to Code Search, Code Navigation, Insights

This ensures:

  • When someone moves teams or leaves, you only change their group membership.
  • Sourcegraph admins don’t manually grant roles.
  • Agentic AI Search and Deep Search respect the same boundaries your engineers already follow.

You can also:

  • Use code host permissions as the first line of defense. Sourcegraph respects those.
  • Layer Sourcegraph‑side RBAC when you need to constrain access to certain orgs, projects, or paths across many hosts.

Testing and cutover plan for 1,000+ devs

Don’t flip the switch for everyone at once. Use a phased model.

Phase 1: Admins and infra

  • 3–5 Sourcegraph admins
  • 1–2 identity engineers
  • Validate:
    • SAML/OIDC login
    • SCIM create/update/deactivate
    • Admin role mapping and emergency access

Phase 2: Pilot engineering group (50–100 devs)

  • Mix of teams (backend, frontend, security, data)
  • Validate:
    • Onboarding flow via SSO
    • Expected repos available via Code Search
    • Deep Search answers are constrained to permitted code
    • Groups and roles behave as expected
    • SCIM handles joiners/leavers in real time

Capture feedback and adjust:

  • Attribute mappings
  • Group filters (especially for large group catalogs)
  • Default roles for new users

Phase 3: Broad rollout

  • Announce Sourcegraph as the standard code understanding platform.
  • Shift from old patterns (ad‑hoc grep, manual repo discovery) to:
    • Universal Code Search across GitHub, GitLab, Bitbucket, Gerrit, Perforce.
    • Deep Search for complex questions.
    • Batch Changes for multi‑repo refactors.
    • Monitors for risky patterns and forbidden dependencies.
  • Confirm security posture:
    • SSO with SAML/OIDC/OAuth
    • SCIM user management
    • RBAC applied consistently
    • SOC2 Type II + ISO27001 compliance
    • Zero data retention for LLM inference.

Have a rollback plan: if something breaks, you can temporarily disable SCIM or revert SSO changes while retaining at least one working admin path.

Governance, auditing, and long‑term maintenance

Once things are stable:

  • Audit access regularly: Compare IdP groups vs Sourcegraph roles to ensure alignment.
  • Standardize group naming: Keep sg-* or similar prefixes for clarity.
  • Instrument monitors: Use Sourcegraph Monitors to detect:
    • Hardcoded secrets
    • Insecure patterns
    • Usage of deprecated libraries
  • Use Insights: Track adoption and migration progress (e.g., how fast teams move off legacy APIs).

This is where Sourcegraph moves from “SSO‑enabled tool” to a real governance and change platform.

Final decision framework

When you’re planning “how do we set up Sourcegraph SSO (SAML/OIDC) and SCIM provisioning with Okta or Entra ID for a 1,000+ developer rollout?” the working model is:

  • Use SAML or OIDC based on your standard, not novelty.
  • Centralize identity and roles in Okta/Entra ID and let Sourcegraph consume them.
  • Turn on SCIM early so you’re never hand‑managing accounts at scale.
  • Map groups to RBAC so Sourcegraph follows the same access model as your other critical systems.
  • Test in phases and keep an emergency admin path.

When this is done right, you have a code understanding platform that every engineer and AI agent can use safely—no shadow accounts, no mystery access, and a clear audit trail.

Next Step

Get Started

Back to AI Codebase Context Platforms

Keep Reading

More from AI Codebase Context Platforms

Sourcegraph MCP Server: what’s required to run a pilot connecting our internal AI agents to permissioned code search and code navigation?

Read more

Sourcegraph rollout plan: how do we pilot with one org/team, measure adoption, then scale company-wide with RBAC and SCIM?

Read more

How do we use Sourcegraph Batch Changes to open and track PRs across hundreds of repos for a dependency upgrade or API migration?

Read more