OIDC (OpenID Connect) and SAML are both protocols that let a firm's staff log into a tool using their existing identity provider account instead of a separate password, but OIDC is the newer, simpler, JSON-based standard that most identity providers and most newly built applications default to today, while SAML is the older, XML-based standard that's still common because large enterprise tools adopted it over a decade ago and haven't moved off it. A firm setting up SSO with a tool for the first time today will usually find OIDC is what's on offer, and that's the right default, not a compromise.
What actually differs, in practice
| OIDC | SAML | |
|---|---|---|
| Setup inputs | Issuer URL, client ID, client secret | Metadata XML, certificates, entity IDs |
| Underlying format | JSON over REST, built on OAuth2 | XML, its own standard going back to the early 2000s |
| Where it's common | Most modern SaaS tools, Google Workspace, Entra ID, Okta's newer integrations | Legacy enterprise software, some government and banking systems, older on-prem tools |
| Typical setup effort for a firm admin | A handful of fields pasted in once | Certificate exchange, more moving parts to get wrong |
Neither protocol is inherently 'more secure' than the other in any way that matters for a CA firm's day-to-day risk. Both, done correctly, hand off authentication to the firm's own identity provider and keep a long-lived secret out of the user's hands. The real difference is ecosystem age and setup friction, not security strength.
Why OIDC became the default
- It builds on OAuth2, which is already how most modern apps handle authorization, so there's one mental model instead of two.
- Setup is a short list of values — an issuer URL, a client ID, a client secret — rather than an XML metadata exchange.
- Every major identity provider a CA firm is likely to already run — Google Workspace, Microsoft Entra ID, Okta — supports OIDC natively and treats it as the primary integration path for new applications.
- Vendors building new products default to OIDC because it's less code, fewer edge cases, and better documented than implementing SAML correctly.
When a firm is still stuck with SAML
SAML hasn't disappeared, and a firm shouldn't expect it to. Some older enterprise software a firm already runs — certain large ERPs, some government portals, a handful of banking or compliance systems — may only support SAML, often because they were built before OIDC existed and nobody has rewritten that integration layer since. In those cases the firm simply runs both: SAML for the legacy system that requires it, OIDC for everything newer, both pointed at the same identity provider. There's no requirement that a firm standardize on one protocol across every tool it uses — the identity provider is the single point of truth either way; the protocol is just how each individual application talks to it.
A firm evaluating a new audit or practice-management tool and finding it only supports OIDC isn't being shortchanged. OIDC-only is a reasonable, modern stance for a tool built in the last several years. It's worth asking a vendor to confirm the protocol explicitly rather than accepting a bare 'yes, we support SSO' — the answer should name OIDC or SAML specifically.
What this doesn't decide
Choosing a protocol says nothing about what happens after authentication succeeds. Whether a logged-in user can see a given client's files is governed by the application's own role and engagement-membership system, not by whether the login used OIDC, SAML, or a password. Protocol choice is purely about how identity gets proven at the door.
How we think about this
Lekhya supports OIDC only, on the Firm plan, against whatever identity provider the firm already runs. SAML is not supported and there's no near-term plan to add it — OIDC covers every identity provider a CA firm is realistically running today, and the simpler protocol means fewer places for a firm's own setup to go wrong.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit workflow & automationSingle sign-on for audit firms: why it matters more at 80 engagements than at eightBelow a certain headcount, SSO is a convenience. Above it, it's the only realistic way offboarding actually happens on the day someone leaves.
- Technology, data & AI in auditAudit software security questionnaire: a buyer's checklistThe questions a firm's own IT or compliance reviewer raises before sign-off, listed so they can be answered before the vendor call, not during it.
- Audit workflow & automationMulti-partner firm technology decisions: who needs to be in the roomA managing partner, an audit partner, and a quality-control partner are evaluating three different things when they look at the same software. Here's what each one actually cares about.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.