OIDC vs SAML for EdTech Identity Federation

Picking OIDC or SAML for an EdTech identity setup is a question about which layer of the stack you're standing in, because higher ed doesn't run on the same trust model as a normal company. Enterprise SSO is bilateral: one company, one identity provider, a handful of apps that all trust it directly. Higher ed is multilateral: hundreds of institutions, hundreds of identity providers, thousands of services, and no single authority telling anyone what to do.

Here's what that actually looks like in practice. A federation operator, InCommon in the US, the UK federation, eduGAIN globally, sets the rules of the road. Member schools register their identity providers and their service providers, and once they're in, they trust each other by membership, not by handshake. So a student at one university logs into a research tool hosted at a totally different university, and neither IT department ever had to call the other. That's the whole point. Trust here runs by association rather than by negotiation, and it only works because everyone agreed to the same rulebook years in advance.

Three pressures sit underneath every identity decision an EdTech team makes, and none of them are going away. First, legacy infrastructure: most campus identity providers have run on Shibboleth and SAML for 15 to 20 years, and that's not getting ripped out on a whim. Second, everything new is mobile-first: modern LMS tools, student apps, and startup integrations are built in REST and JSON with mobile SDKs, not XML parsers. Third, cross-institutional trust has to happen without anyone centralizing control. A student's home school vouches for them, the school on the other end has to accept that vouch, and neither one wants to own the relationship.

This is also where a lot of cloud identity vendors quietly mislead people. When a vendor says their product "supports federation," they usually mean bilateral SAML, one login, one company, one app. That's a much narrower model than the multilateral one higher ed actually needs, and campus identity managers know it the moment they try to explain to a provost why the shiny new cloud IdP still doesn't solve cross-institution trust. So the real question was never "which protocol wins," but which protocol handles these three pressures at the specific layer your institution sits in.

How SAML became the load-bearing wall of campus identity

SAML 2.0 didn't arrive from some generic enterprise IT committee. The Shibboleth project, run out of Internet2, helped write the SAML 2.0 spec that got ratified in 2005, and that means cross-institutional research and education trust was baked into the protocol from day one, not bolted on after.

Shibboleth is the practical result. It's open-source middleware, and it's the reference implementation of SAML across higher ed worldwide, running everywhere from large research universities to smaller institutions worldwide. When a campus identity manager says "our IdP," they mean a Shibboleth box humming away in a server room somewhere — the literal software, not a figure of speech.

The federation infrastructure sitting on top of that is enormous. InCommon connects more than 1,000 institutions, companies, and federal agencies. The UK federation counts over 1,200 member organizations across higher ed, further ed, research, and commercial partners, and it's wired into more than 70 national federations around the world. eduGAIN ties all of that together globally, serving more than 27 million users through upward of 6,000 connected identity providers. As of 2025, 85% of universities use SAML for federated identity management, according to MojoAuth. Whatever comes next has to reckon with that number.

Part of why SAML stuck is that its XML assertion model does something campus IT actually depends on: it carries rich, structured attributes. eduPerson fields like affiliation, entitlement, and scoped affiliation ride along in the assertion itself, and campus authorization logic has been built around exactly those fields for two decades. The assertions are signed XML, trusted without a back-channel call, which matters in high-latency or air-gapped research environments where phoning home isn't an option. And the whole thing scales through metadata: federation metadata files list every registered IdP and SP, so trust happens at scale without anyone configuring bilateral relationships one at a time. Ask "do we still need SAML" and the installed base answers for you: yes, at minimum as a compatibility layer.

What OIDC's architecture actually looks like and where it fits differently

OIDC showed up in February 2014, put together by the OpenID Foundation with backing from Google, Microsoft, and others. It wasn't built from scratch. It's an identity layer stacked on top of OAuth 2.0, which already tells you something about its design priorities: web-scale consumer login, not campus research federation.

The architecture reflects that. Tokens are JWTs, plain JSON, not XML documents, so they're smaller and easier to parse on a phone or in a browser. Verification leans on back-channel token checks or public key validation instead of passing signed XML around in the browser. And the whole flow, redirects, token exchange, was designed around REST APIs, single-page apps, and mobile apps from the start, on devices where nobody wants to parse XML.

OIDC is already everywhere in EdTech, most people just don't clock it as OIDC. Every "Sign in with Google" button on a campus tool, every Microsoft SSO prompt, that's OIDC running under the hood. Okta, Auth0, Azure AD B2C, Ping: all of them treat OIDC as the primary protocol for anything modern. Developers tend to prefer it too, if only because library support is wider across languages and frameworks, while SAML's XML handling has a long history of producing implementation bugs (more on that shortly).

Where OIDC struggles is the federation layer itself. There's no built-in equivalent to SAML metadata federation, so bilateral configuration is the default, which is exactly the model higher ed can't scale to thousands of institutions. Attribute release is a similar story: eduPerson and the broader research-and-education attribute bundles are mature and standardized in SAML, and OIDC's claims-based equivalents exist but haven't reached the same level of cross-campus consistency. OIDC is a strong fit for the apps layer and a poor fit, historically, for the federation layer. That gap is exactly what the next two sections are about.

LTI 1.3 is why OIDC is already inside every modern LMS integration

LTI 1.3, the current integration standard from 1EdTech (formerly IMS Global), runs on the 1EdTech Security Framework, and that framework is built on OAuth 2.0 and OIDC with signed JWTs. Every earlier version of LTI is deprecated by the spec itself. There's no legacy fallback path here.

What that means in practice: any tool that plugs into a modern LMS through LTI 1.3 is, by definition, an OIDC Relying Party. Canvas, Moodle, Blackboard, and Brightspace all implement the same LTI 1.3 OIDC login handshake. The LMS kicks off the OIDC launch, the tool validates the JWT that comes back, and grade passback (AGS) and roster access (NRPS) both ride on OAuth tokens after that. For EdTech vendors, that turns OIDC fluency into table stakes for LMS integration, completely separate from whatever protocol the school's own identity office runs.

That creates a layered setup most institutions never explicitly designed, they just ended up there. The campus identity provider is still Shibboleth and SAML in the overwhelming majority of cases. The LMS platform speaks SAML to that identity provider for student login, then turns around and speaks OIDC and LTI 1.3 to every integrated tool. The tools themselves are OIDC Relying Parties whether the campus identity team planned for that or not. For a developer wondering where to spend engineering time first, LTI 1.3 with grade passback covers login, roster access, and gradebook writes in one standard, so the OIDC investment pays off in three places at once. Institutions are now running SAML and OIDC at the same time, in the same stack, which turns this from an either/or choice into a question of placement.

Security vulnerabilities in each protocol and what they mean for campus environments

SAML's weak point traces straight back to XML. XML Signature Wrapping, XSW, is the vulnerability class that keeps coming back: early research found 11 of 14 tested SAML implementations were vulnerable to it, and patches from Spring Security, OpenSAML, and various commercial vendors have kept shipping through the 2020 to 2025 window. GitHub Security Lab disclosed a "sign in as anyone" bug in ruby-saml in 2025, and it followed the same XSW pattern researchers have been flagging for years. The root cause is structural: XML canonicalization rules leave room for parsers to disagree with each other, and that gap is genuinely hard to close for good.

OIDC and JWT have their own history, just a different shape. The "alg: none" disclosure back in 2015 showed that some JWT libraries would accept a completely unsigned token if the algorithm field said not to check it. In 2024, researchers documented JWT confusion attacks, swapping an RS256 token for one signed with HS256 using the IdP's own public key as the secret, and several Node.js and Python libraries were affected. A CAS OIDC plugin had a client-ID validation bug in 2024 that opened the door to impersonation. IBM Verify and Apache APISIX both turned up issuer-mismatch bugs in multi-tenant setups between 2024 and 2025.

So what does the comparison actually tell an EdTech decision-maker? SAML's XML canonicalization surface produced a disproportionate run of high-severity, actively exploited bypasses between 2024 and 2026, which tilts the structural risk argument toward OIDC for anything new being built today. OIDC's problems, by contrast, read more like implementation quality issues, fixable by keeping libraries current and enforcing algorithm checks properly. But that cuts both ways: a well-maintained Shibboleth instance running current patches carries a different risk profile than a custom XML parser nobody's touched since 2019. NIST SP 800-63C-4, published in 2025, treats both protocols as valid at every assurance level, so this was never really a compliance question, but rather one of implementation quality and patch hygiene. Shibboleth's open-source, community-maintained model means fixes do propagate out to most university deployments, but any school running an old, unpatched version, and under-resourced IT shops do exist, is carrying real XSW exposure right now.

OpenID Federation 1.0 and the active effort to port multilateral trust into the OIDC world

OIDC has no native answer to SAML's metadata federation, and bilateral configuration simply doesn't scale to thousands of identity providers and service providers spread across national federations. OpenID Federation 1.0 is the attempt to fix that.

The trust model works through signed trust chains: entities trust each other through a shared trust anchor, which is conceptually the same idea as SAML federation metadata, just expressed in JSON instead of XML. It's designed to be decentralized, supporting thousands of identity providers without any single metadata authority sitting in the middle. And it fixes one of SAML's real weak spots: XML canonicalization makes it painful to migrate cryptographic algorithms over time, while JSON-based trust chains don't carry that same baggage.

The clearest signal that this is more than a whitepaper exercise: eduGAIN launched a 12-month pilot in July 2025, part of the GN5-2 project, specifically to test OpenID Federation as a future trust technology running alongside the existing SAML setup. Nobody's replacing SAML yet; this is explicitly about testing whether the two can coexist and how a transition would actually work mechanically. The push is happening now because XML and SAML tooling is getting less maintained as an ecosystem, standardization has slowed, cryptographic agility is a known pain point, and metadata management at scale is getting harder, all reasons InCommon and GÉANT point to directly.

InCommon's own position is measured: the existing federation infrastructure stays SAML-based for the foreseeable future, while InCommon tracks OpenID Federation and leans on federation proxies as the near-term bridge, adapters that double as authentication brokers between InCommon and OIDC-native apps. There's also momentum coming from outside R&E entirely: European work to fold eduGAIN into the EU Digital Identity Wallet framework is using OpenID Federation as the underlying mechanism, which gives this transition institutional weight beyond just university IT departments. For anyone making a protocol call today, the honest read is that OpenID Federation is real and funded, but a 12-month pilot plus "foreseeable future" SAML language points to a 2 to 5 year horizon before production multilateral OIDC federation runs at InCommon or eduGAIN scale. This is not an imminent cutover.

Where each protocol belongs in a realistic EdTech stack right now

Most institutions are already running both protocols, whether anyone planned it that way or not. So the real question is placement, not victory.

Break it down by layer and the picture gets simple fast. Campus identity provider talking to institutional federation, InCommon, the UK federation, eduGAIN: SAML is required today, full stop. OpenID Federation support is coming but on a multi-year runway, and there's no practical substitute for this layer in 2025 or 2026. LMS talking to EdTech tools through LTI 1.3: OIDC is required by the specification, no alternative available. A tool that skips the LTI 1.3 OIDC handshake simply cannot integrate with Canvas, Moodle, or Blackboard through the current standard. Modern student-facing apps, mobile clients, and public APIs: OIDC is the right call there too, JSON and JWTs fit mobile SDKs naturally, the flows are REST-native, and the developer tooling is far deeper than anything available for SAML on these surfaces.

Line those three up and the "which protocol is better" framing falls apart on its own. SAML still carries the weight of institutional trust because nothing else has replaced it at that layer yet. OIDC already runs the app layer because it was built for exactly that job. Neither one is waiting for the other to lose.