Episode 182 - GluuFederation/identerati-office-hours GitHub Wiki
Title: SAML v. OpenID Connect v. OAuth
- Host: Mike Schwartz, Founder/CEO Gluu
- Guest: Mark Dobrinic, Software Developer and Identity Specialist at [Curity](https://curity.io]
Channels
Description
OAuth, OpenID Connect, and SAML are foundational protocols for modern identity and access management—but they were designed to solve different problems and are often misunderstood. In this episode of Identerati Office Hours, we unpack how OAuth focuses on delegated authorization, how OpenID Connect layers identity on top of OAuth, and why SAML still powers many enterprise single sign-on deployments. Join us for a practical discussion on when each protocol fits best, how they interoperate, and what developers and architects should consider when choosing among them.
Homework
Takeaways
-
⚡ SAML and OpenID Connect have functional overlap, but they come from different places. SAML was designed by enterprise. OAuth and OpenID were adopted by enterprise after the fact.
-
⚡ While SAML is definitely stable, libraries and dependency chains still result in CVEs and ongoing security and maintenance risk. XML libraries are frequently the culprit. One strategy is to minimize your SAML footprint, because some of the CVEs might relate to an esoteric SAML feature you're not using anyway.
-
⚡ SAML was maybe a little over-engineered. It also uses old-timey abstruse jargon. But... some SAML features are actually gaining traction in OpenID-OAuth world, for example CMID--who knew RP metadata would be so useful.
-
⚡ SAML is still ahead in federation, based on the number of deployments in production. And if SAML and OpenID are functionally the same, there is little value in updating these federations to a newer standard.
-
⚡ SAML is not "bigger"--there are 32 OAuth RFCs and a dozen or so OpenID Connect standards. SAML doesn't anticipate mobile device user agents. There are no browser-based SAML SPs that can't protect secrets. So where there is overlap--in web-based user authentication--it is very detailed. But it wasn't designed to solve the challenge we're facing today with an exponential increase in software and data.