Preface: A question was raised on a FIDO forum recently on what "best practices" exist for integrating 0Auth2 with FIDO2 to enable Single Sign-On (SSO) to applications. While the poster was seeking a technical answer to his problem, the question awakened simmering concerns in my mind about SSO when combined with FIDO. I responded with the following answer and have decided to share this with other cybersecurity/identity professionals, application architects and software programmers so they might ponder the value of simplifying their applications in this complex arena.
In light of what FIDO brings to the authentication space, I am going to challenge you (and others) to question your premise around SSO technology. The goal is not to put anyone on the defensive about any specific SSO technology, but to debate whether SSO is even necessary in light of what FIDO offers.
You have to step back into the late 1980's and early 1990's to understand why SSO was really needed. Enterprises were operating a complex conglomeration of technology solutions at the time: mainframes running Systems Network Architecture (SNA) Logical Unit (LU) 6.2 mini-computers with DECNet and other proprietary protocols, Netware LANs, a smattering of UNIX systems running TCP/IP, and OS/2 with LAN Manager, etc. Everybody was using usernames and passwords. And, everybody had different schemes, algorithms, and protocols for dealing with them. The complexity of managing this was daunting enough that companies were investing serious money to solve this problem.
As networks were starting to coalesce around TCP/IP and public-key cryptography made a splash, for a while in the late 1990's, it seemed that the password problem could be eclipsed by that original passwordless authentication protocol: Secure Socket Layer (SSL) ClientAuth with X.509 v3 digital certificates. But that bubble broke with the the dot-com crash; and passwords that were restricted to enterprise networks at the dawn of the worldwide web, exploded to affect every consumer that needed to authenticate to a restricted website leading use to where we are today-- a complex conglomeration of SSO protocols and schemes.
FIDO is, essentially, a reboot. An advanced authentication technology that:
- Does NOT depend on "shared secret authentication"
- Is designed to protect the privacy of consumers
- Can optionally leverage simple to sophisticated "user verification" schemes
- Eliminates password phishing attacks
- Is supported on every modern client computing device (many with secure elements)
- Is supported on every modern browser
- Most importantly, is simple enough that it can strongly authenticate users with the touch of a button
If a FIDO server can authoritatively return an authentication token in a few seconds to any web/mobile application, why burden the application with a legacy SSO protocol that adds yet another "band-aid" to what was already a band-aid from the previous century? Why not eliminate the "man-in-the-middle" and just get an authoritative answer from the source?
SSO tokens-- whether they are Security Assertion Markup Language (SAML), JSON Web Token (JWT) or another proprietary schemes-- must be verified thoroughly because they represent a "man-in-the-middle" (MITM) of the authentication flow. Why introduce or maintain a MITM when the protocol was designed for privacy violations when the MITM is breached?
Ah! The answer is "legacy applications. SSO was written into applications in age when passwords ruled the world and companies needed to alleviate the burden of users who were forced to authenticate to dozens of systems within the enterprise. The cost of SSO was sufficiently less than the cost of the loss of employee productivity combined with the cost of employee frustration with password management, that SSO established itself within the enterprise and is now accepted as a defacto standard.
But, when passwords have been eliminated and strong authentication bas been simplified, does it make sense to continue carrying the SSO cost? The technical complexity? And, the legal burden in a world increasingly regulating privacy? (Note that similar questions arise when considering this issue raised with passkeys held by platform vendors-- but we will deal with passkeys in another article.).
It may be useful to step back and ponder whether it may benefit the Internet to eliminate the SSO burden-- and its associated risks-- when an application can get an authoritative answer from a FIDO server directly with the simple touch of a button, faster than it can verify the authenticity and integrity of an SSO token.
About StrongKey
StrongKey is the leading provider of open-source strong authentication and data protection solutions. Founded in 2001, StrongKey helps FinTech, enterprise, pharmaceutical, manufacturing, and e-commerce companies protect their data. The StrongKey Tellaro is a comprehensive solution that delivers passwordless FIDO strong authentication, encryption, tokenization and key management (including X.509 digital certificates). Unlike other security solutions, StrongKey provides its solutions with open-source licensing, thereby eliminating transaction, or per-user fees and making it one of the most cost-effective security solutions in the world. StrongKey Tellaro appliances use FIPS 140-2 Level 2 (standard) and Level 3 (optional) validated cryptographic hardware modules to secure the generation, use and storage of cryptographic keys to comply with U.S. Federal regulations.
To learn more about StrongKey and our solutions, email us at getsecure@strongkey.com.
