🔎 MYTHBUSTERS: IS SSO ALWAYS SECURE?

🎬 The Experiment Begins...

‍

‍

Today on MythBusters, we’re putting to the test a widely believed cybersecurity myth:

“SSO is completely secure and eliminates all risks.”

Sounds great, right? No more password headaches, fewer logins, and a seamless experience. But what if we told you... that might not be entirely true?

To find out, our lead investigator Adam is teaming up with Jamie, our in-house security expert. They’re going to put SSO to the test and see where it might fail.

Let’s bust some myths!

🔥 MYTH #1: “The SSO Provider Cannot Be Compromised”

‍

‍

The Setup

In order to receive a secure authentication token, Adam needs to log into his Google account. In order to do so, Adam is using his email and a strong password that he remembers well.

But what if an attacker knew Adam’s password? Or what if an attacker was able to mimic the Google login page? Would they be able to use it to eventually impersonate Adam?

The Experiment

Jamie sets up a phishing attack—a fake Google login page that looks exactly like the real one. Adam, thinking it’s legit, enters his username and password.

BOOM. Jamie can now log into Google as Adam and uses his stolen credentials to log into all the company’s apps.

The Result

✅ Myth Busted! SSO natively creates a Single-Point-Of-Failure that attackers are eager to exploit, and often do it in real life.

How to stop this from happening?

• Use a password manager to avoid employees using weak passwords or reusing password across applications
• Use Multi-Factor-Authentication (MFA) on your SSO provider (like a physical security key or biometric login).
• Train employees to spot phishing attacks and verify links before entering credentials.

🔥 MYTH #2: “Stolen Tokens Are Useless”

‍

‍

The Setup

In order to get access to his apps Adam gets a secure authentication token from his SSO provider that is passed to the applications. This token is his golden ticket—it proves to all apps that he’s Adam and that he’s allowed in.

But what if an attacker gets their hands on it? Would they be able to use it and impersonate Adam?

The Experiment

Jamie sets up a man-in-the-middle attack (MIM attack)— for example by installing a compromised web browser on Adam’s computer. Adam, unaware that any action data transferred is copied by an attacker, simply logs in with his SSO.

BOOM. Token stolen.

Jamie now uses Adam’s stolen token to log into all the company’s apps.

The Result

✅ Myth Busted! Stolen tokens can be used just like real ones, it is called a “token replay attack”. While it is a sophisticated attack, it represents 5% of all identity attacks, and has doubled in volume over 2024.

How to stop this from happening?

• Use modern browsers that are less prone to MIM attacks
• Protect your endpoints laptops and mobile phones can be infected by malwares
• Protect your networks with WEP/WAP Encryption and make sure to change your router’s admin credentials
• Make sure the websites you visit are using HTTPS
• Use secure VPNs when on public WiFi

⚡ MYTH #3: “Expired Tokens Cannot Be Used By Apps”

‍

‍

The Setup

SSO tokens should expire after a while. That way, if someone steals an old token, it’s useless.

But what if an app doesn’t check whether the token is expired?

The Experiment

Adam is offboarded from the company. His Google account is disabled, so he shouldn’t be able to log in anywhere.

Jamie, however, tries to use an old token Adam had before his account was disabled.

Surprisingly… it still works on many applications!

The Result

✅ Myth Busted! Some apps don’t properly check token expiration or revocation.

How to fix this?

• Audit token lifetimes regularly and enforce short expiration times.
• Make sure apps check token validity with Google every time a login happens.
• Automatically revoke tokens when an employee leaves the company.

⚡ MYTH #4: “Applications Require Login Every Time”

‍

‍

The Setup

Adam’s company has a strict SSO policy. Accounts are automatically disabled when employees leave.

That should mean ex-employees can’t access anything, right?

The Experiment

Adam has left the company, and Jamie has taken his laptop and deleted his Google account.

Adam, however, was logged into several company applications on his smartphone, and still receives notifications.

When following the notifications, Adam realizes he can still see all the conversations with his colleagues and the latest message from the CEO!

Why? Because the apps didn’t check with Google to see if his SSO access was revoked.

The Result

✅ Myth Busted! Most developers don’t want their users to have to login every time they open their application, thus their user sessions often outlive the authentication token by many months (if not forever when the session is set to never expire!).

How to fix this?

• Enforce session expiry rules to your third-party vendors
• Close accounts inside all applications when an employee leaves the company
• Automate as much as possible to remove human error from the equation

🕵️ MYTH #5: “SSO Covers Every App”

‍

‍

The Setup

SSO is great… but only if it’s actually used.

Adam’s company uses Google SSO for most apps, but some employees have started using “unofficial” tools—a classic case of Shadow IT.

The Experiment

Jamie finds out that some employees are using third-party apps that aren’t connected to Google SSO. These apps only require a simple email + password login.

And guess what? These logins have weak passwords and no two-factor authentication.

Jamie tries to brute-force a few logins… and within minutes, he’s in.

The Result

✅ Myth Busted! SSO only secures apps that are actually using it—Shadow IT is a serious security hole.

How to fix this?

• Require all apps to go through Google SSO whenever possible.
• Identify and monitor unauthorized tools used in the company.
• Educate employees about the risks of using non-approved apps.

🔎 THE FINAL VERDICT: IS SSO ALWAYS SECURE?

After all these tests, what’s the conclusion?

🚨 MYTH BUSTED! 🚨

SSO is not automatically secure—it depends on how well it’s implemented and maintained.

🔴 The biggest risks?

• Stolen tokens can be misused if multi-factor authentication isn’t enforced.
• Expired tokens might still work if apps don’t properly check their validity.
• SSO doesn’t cover everything—Shadow IT can introduce serious vulnerabilities.
• Human error (like failing to revoke access) can leave security holes.

🛠️ The Fix?

• Strong authentication methods (like security keys).
• Strict expiration and revocation policies for tokens and for account.
• Full visibility into all apps used by employees.
• Automated offboarding to remove human error.

‍

🎬 Closing Thoughts

Adam leans back, taking in everything he’s learned.

Adam: “Wow, I always thought SSO was a silver bullet, but it looks like it still needs a lot of security layers.”

Jamie: “Exactly! SSO is like a seatbelt—it keeps you safe, but only if you actually buckle up and check for wear and tear.”

Adam: “Good thing we tested it… Speaking of tests, maybe it’s time to run a security check on our systems.”

Jamie: “Now that’s an idea I can get behind.”