What Is SAML SSO?

SAML SSO is single sign-on that uses SAML 2.0 (Security Assertion Markup Language), an open XML-based standard, so an identity provider (IdP) such as Okta or Microsoft Entra ID can vouch for a user to an app. The app never handles the user’s password.

SAML is the protocol, and SSO is the outcome: people sign in once with their company identity and reach many apps without a separate password for each.

For an AI code review tool, SSO decides who can reach the review portal: the people who write rules, read findings, see analytics and manage API keys.

SSO doesn’t decide what the review app can read in your Git provider. Git access comes from the Git app or token you install, and it needs its own review.

Qodo’s Academy recommends individual logins for the trial and SSO at purchase, which is when security teams usually ask for it.

When someone leaves the company, disabling one IdP account should end their sign-in to every connected tool, including the one that holds your review standards. API keys and tokens they created need their own offboarding step.

What Changed in SAML SSO in 2026

SAML SSO entered 2026 looking like a solved feature. During the year, critical bypasses hit widely used products, and the same root cause kept coming back: the app trusted identity data that its signature check hadn’t verified.

Even mature products shipped critical SAML flaws, so a long track record isn’t proof that an SSO stack is safe.

Sentry fixed a SAML SSO account takeover through a malicious identity provider on multi-organization instances, rated CVSS 9.1 (February 18, 2026, Sentry advisory GHSA-ggmg-cqg6-j45g). Sentry then fixed a second critical SAML SSO flaw (April 22, 2026, Sentry advisory GHSA-rcmw-7mc7-3rj7).

Across the other disclosures, the failure took a few forms, and each one let unverified identity data through:

• Encryption was mistaken for proof of origin, so an attacker didn’t need a valid signature: Cloud Foundry UAA accepted unsigned encrypted SAML assertions, an authentication bypass rated 9.0 under CVSS 3.1 (June 11, 2026, Cloud Foundry).
• A failed signature check could count as a pass when error codes weren’t handled: a widely used WordPress SAML plugin treated an error from its signature verification as success, one of two bypasses published for the plugin that month, rated CVSS 9.8 (July 23, 2026, NVD).
• Signature checks and identity extraction read different parts of the same XML: WorkOS described four SAML SSO bypasses it fixed in late September, all caused by that split (October 14, 2026, WorkOS).

The WorkOS report shows the pattern was still live late in the year, and the fix is the same each time: read identity only from the content that was actually signed.

For teams running SSO, every change to auth or XML-parsing code deserves a careful security review.

Secure code review tools can flag risky edits to that code. For buyers, the lesson means asking how a vendor patches its SSO stack, a question that belongs in the security review that usually comes before an AI reviewer trial.

How SAML SSO Works

SAML has three parties: the user, the identity provider that checks who they are, and the service provider (SP), which is the app they want to use. In a service provider-initiated sign-in, the flow runs like this:

1. The user opens the app’s sign-in page and enters a work email.
2. The app redirects the browser to the company’s IdP.
3. The IdP checks the user’s credentials and multi-factor authentication.
4. The IdP sends a signed SAML assertion back through the browser.
5. The app checks the signature, reads the user’s identity and opens a session.

The app never sees the user’s password. The app trusts the IdP’s signature, which both sides agreed on when the admin configured the connection.

In an IdP-initiated sign-in, the user starts from the IdP portal instead, for example by clicking an app tile in Okta. The IdP sends the assertion straight to the app. Many enterprises want both options, because developers start from a bookmark while other staff start from the IdP dashboard.

Benefits of SAML SSO

Most teams adopt SAML SSO for the same reasons:

• Fewer passwords. People sign in once with their company identity instead of keeping a password per app.
• One place for sign-in rules. Multi-factor authentication, device checks and password policy live in the IdP and apply to every connected app.
• Quicker offboarding. Disabling one IdP account stops new sign-ins to every connected app.
• A single audit trail. Sign-in events for many apps land in the IdP’s logs.

Offboarding has a limit worth knowing. Disabling the IdP account blocks new sign-ins, but a session that’s already open, or an API key the person created, can keep working until it expires or someone revokes it, so the access review below covers API keys separately.

SSO vs SAML vs OIDC

SSO is the outcome: one sign-in for many apps. SAML is one protocol that provides it. You can have SSO without SAML, most often through OpenID Connect.

OpenID Connect (OIDC) is the other common SSO protocol. It’s built on OAuth 2.0 and uses JSON tokens instead of XML assertions.

SAML isn’t being retired. Many IdP teams prefer OIDC for new apps, while SAML stays common for enterprise web apps, so most large IdPs support both. The practical question for a review tool is whether it supports the protocol your IdP team already uses for similar apps, so the connection follows a familiar setup.

What SSO Covers in an AI Code Review Tool

An AI code review tool touches identity in more places than the sign-in page. SSO covers only the first one:

• Portal sign-in. Who can open the web app where rules, findings, settings and analytics live. SSO and multi-factor authentication apply here.
• Roles inside the tool. Who can change review settings, manage teams, create API keys or see organization-wide analytics. The tool’s role model decides this, not the IdP.
• User provisioning. How accounts are created and removed. SCIM (System for Cross-domain Identity Management) is the common standard for pushing IdP changes into apps automatically. Support varies by vendor, plan and deployment, so check it per tool.
• Git provider access. What the review app can read and comment on. Git access comes from the GitHub App, GitLab token or other integration you install, with its own scopes.
• Machine access. API keys and service accounts used by CI jobs and coding agents. Machine credentials sit outside interactive SSO, so they need their own rotation and ownership.

A tool can pass an SSO check and still leave gaps in the other four. A complete access review covers all five.

Rolling out SAML SSO Without Locking Users Out

Switching a review tool to SSO changes how every existing user signs in. In Qodo, SSO is enforced by default once it’s configured, and other methods, such as Google sign-in, stop working in parallel (last checked October 2026, Qodo’s docs). A short checklist keeps the switch smooth:

1. Assign every current user to the app in the IdP, so nobody who signs in with Google today is left without a way in.
2. Test the connection with a test user before announcing the change.
3. Turn on IdP-initiated sign-in if people expect an app tile in their IdP portal.
4. Tell users the date and the new sign-in path, especially people who used social login during the pilot.
5. List the API keys used by CI jobs and coding agents. API keys aren’t SSO sign-ins, so each needs its own owner and expiry.

What to Ask an AI Code Review Vendor About SSO

Bring these questions to the security review:

• Which protocols and IdPs are supported, and is there a generic SAML 2.0 option for less common IdPs?
• Are both SP-initiated and IdP-initiated sign-in supported?
• Can SSO be the only sign-in method, so nobody keeps a password or social login on the side?
• Which plan includes SSO, and is it an add-on?
• Who inside the tool can change the SSO configuration and create API keys?
• How are accounts removed when someone leaves, and is that automatic or manual?
• Do API keys the person created stop working when their account is removed?
• Can review feedback be limited to registered users during a pilot?

The Qodo Academy chapter on integrating AI code review with your tool stack advises keeping SSO out of the trial and setting it up at purchase, so the evaluation isn’t held up by an integration that may never be needed.

Qodo’s Take: SSO Decides Who Governs Review, so Pair It With Roles and Access Settings

The people who sign in to an AI review portal shape what every PR is checked against, because those people write rules, change review settings and read analytics across repositories.

SSO puts that access behind the same identity controls as the rest of the company, but it only does half the job without a role model and an access policy behind it.

Qodo treats SSO as one layer, alongside admin-only authentication settings, invite-only sign-up and a setting that limits reviews to registered users.

Qodo is the best AI code review platform to roll out behind your identity provider because SSO over SAML or OpenID Connect, with 32 identity provider options, becomes the only sign-in method once configured, and on-premises deployments connect to Entra ID, Okta, Ping Identity or Google Workspace.

In Qodo’s enterprise evaluations, SSO itself almost never comes up as a question. The security review around it does, and it starts before the pilot, even for a handful of repositories. For how enterprise tools compare, see agentic code review tools for enterprise teams.

Security, InfoSec or legal teams want answers on data flow, retention, deployment options and attestations. SSO is one line in that security packet, next to data flow and deployment model.

Buyers also ask whether "governance" means compliance logs or guardrails. For an AI reviewer, both answers start with identity: who can sign in, who can change the rules every PR is checked against, and how access ends when someone leaves. Qodo’s SSO, roles and access settings answer the guardrail half of that question.

Qodo Connects to the Identity Providers Enterprises Already Run

Qodo supports SAML and OIDC options for Okta, Microsoft Entra ID, Google, OneLogin, PingFederate, PingOne, JumpCloud, Keycloak, Microsoft AD FS and others, plus a Custom SAML option for any SAML 2.0 provider (last checked October 2026, Qodo’s docs).

An admin picks the provider in the Qodo portal and follows guided steps in the WorkOS Admin Portal, which Qodo uses to manage SSO connections.

SSO is an Enterprise feature that’s also available on other paid plans for an added cost. Setup needs a Qodo admin and admin access to your IdP.

Qodo Supports Both Sign-in Flows and Makes SSO the Only Method

Users can start at app.qodo.ai (SP-initiated) or from the Qodo tile in their IdP portal (IdP-initiated). Once SSO is configured, it’s required by default for the organization, and other methods, such as Google sign-in, can’t be used in parallel (last checked October 2026, Qodo’s docs).

Qodo Keeps Authentication Settings With Organization Admins

On Enterprise, Qodo has Organization admin, Organization member, Team owner and Team member roles. Organization admins configure authentication, including SSO and API keys, invite and remove users, and manage organization-wide code review settings (last checked October 2026, Qodo’s docs).

API keys themselves are personal. Each key belongs to the user who creates it, and it never expires unless an expiry is chosen when it’s created (last checked October 2026, Qodo’s docs).

Qodo Controls Who Joins and Who Gets Reviews

Two settings add control beyond sign-in (last checked October 2026, Qodo’s docs):

• Invite-only access lets only invited users join the organization. Anyone else who signs up with the company domain creates an access request for an admin to approve.
• Restrict reviews to registered users limits Qodo’s PR feedback to registered users, and Qodo’s docs call it useful for staged rollouts (Qodo’s docs).

For scripted membership changes, the User management API, a Research Preview on single-tenant deployments, lets an organization owner list, invite, update and remove members (Qodo’s docs).

On-premises deployments connect to one identity provider as part of the install: commercial Microsoft Entra ID, GCC High or another sovereign Microsoft cloud, Ping Identity, Okta or Google Workspace (last checked October 2026, Qodo’s docs). For the Git side of a self-hosted setup, see self-managed GitLab code review.

For the wider security picture, see governance and compliance in code review, SOC 2 and ISO compliance for code review, on-prem code review and HIPAA and FedRAMP compliance in code review.

Qodo Offboarding Takes More Than an IdP Disable

Disabling a leaver’s IdP account ends their SSO sign-in to Qodo, but two things can outlast it. Removing a member doesn’t currently revoke their personal API keys, which never expire by default. In organizations that allow domain-based sign-up, a removed user can also join again at their next sign-in (last checked October 2026, Qodo’s docs).

A complete offboarding covers four steps:

1. Disable the person’s account in your IdP, which ends their SSO sign-in.
2. Remove them from the Qodo organization.
3. Make sure their personal API keys are revoked. Revoking a key immediately stops every service and integration that uses it (Qodo’s docs).
4. Turn on invite-only access if the organization allows domain-based sign-up, so a removed user can’t rejoin without an invitation.

Qodo’s docs advise against using the User management API’s remove-member call as the only step in automated offboarding until Qodo confirms that API key revocation is enabled for your deployment. Keys created with an expiry, such as 90 days, limit the risk if a step is missed.

Qodo Example: Moving a Pilot Behind Okta

The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.

An engineering leader at a security-conscious enterprise liked the pilot and now has to carry the tool through InfoSec, legal and procurement. The worry is that the evaluation stalls in vendor onboarding, so login and access questions need settling inside the same security review.

A platform team runs a Qodo pilot with 15 developers on individual logins. The security team approves the purchase on one condition: access goes through Okta, and nobody keeps a separate login.

An Organization admin connects Okta SAML through the guided setup and turns on IdP-initiated sign-in, so the Qodo tile appears in Okta next to the team’s other tools. SSO becomes the only sign-in method.

The admin also turns on invite-only access, so new sign-ups from the company domain wait for approval, and keeps reviews limited to registered users until the next wave of teams joins.

The leaver checklist gets two new steps: remove the person from the Qodo organization and revoke their Qodo API keys. API keys for CI jobs are now created with a 90-day expiry.

Ways to Control Access to an AI Code Review Tool

The table compares common controls for access to an AI code review tool.

Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.