Single sign-on and identity federation make life easier for users. Instead of creating another username and password, people can sign in with an account they already have.
But that convenience only works if the trust between the two systems is set up correctly.
The recent Lenovo ID–Dropbox incident is a good example of what can go wrong when that trust is too broad.
Around 5,000 Dropbox accounts were affected after attackers were able to abuse a federated connection between Lenovo ID and Dropbox. A misconfiguration allowed someone to create a Lenovo account using another person’s email address and then use that Lenovo identity to access the Dropbox account connected to the same email address.
The key problem was simple:
Just because two accounts use the same email address does not automatically mean they belong to the same person.
The reason behind this problem? Not so much.
Where did the problem come from?
Dropbox allowed users to sign in through Lenovo ID.
That in itself is not unusual. At IdentIT we have implemented similar mechanisms at many companies by connecting their identity systems. Microsoft Entra ID, Google, Facebook,… Most of us use these identity providers daily for logging into our applications.
The problem starts when one system places too much trust in information coming from the other.
In this case, the email address appears to have played an important role in connecting the Lenovo identity with the existing Dropbox account.
An email address is useful for identifying a user, but it should not by itself be enough to give someone access to an existing account.
This type of problem is not new and has been highlighted in previous research around so-called “nOAuth” attacks, where applications automatically connected accounts based on matching email addresses.
What could have prevented this?
This is a classic case of a “double whammy”. On the one hand, we have an identity provider that misconfigured their account creation process and allowed users to create accounts with email addresses they do not own. On the other hand we have a service provider (Dropbox) that blindly trusts email addresses passed on by the aforementioned identity provider.
There is no single security setting that solves every federation problem. Secure federation depends on how the full login and account-linking process is designed.
However, several controls could have significantly reduced the risk in this case.
Do not automatically connect accounts based only on email
This is probably the most important point. Let’s break it down.
Imagine that a Dropbox account already exists for john@example.com.
Someone then logs in through another identity provider using the same email address.
The application should not simply conclude:
“Both accounts use john@example.com, so they must belong to the same person.”
This is where magic was missing. First, their Dropbox account should have been marked as having a connection with Lenovo ID. This is an essential part of the trust relation that should have been set up. Multiple accounts were known to have never set up a Lenovo account, so why were they able to login with one?
Second, the user should be asked to prove that they already own the existing Dropbox account.
Of course, this works against the convenience of having “one single sign-on”, so having a streamlined way of verifying yourself is essential here. Yes it is 2026, so yes you should have enabled MFA for your account. This is not about pointing fingers at users or Dropbox. Strong authentication is a shared responsibility.
Be careful about what you trust from another identity provider
When one company accepts identities from another company, part of its security now depends on that other company’s processes.
For example:
- How are new accounts created?
- How are email addresses verified?
- What happens when a user changes their email address?
- How does password recovery work?
- Can administrators change user information?
- Is MFA available?
- What happens if an account is compromised?
These questions are one of the most important we ask when we onboard identity providers at our customers. Setting up a trust relation is not just a matter of exchanging some metadata, it is about understanding the impact of each other’s processes.
Add extra verification when a new login method is connected
Let’s assume Dropbox did check whether an account was already linked to a Lenovo account. Couldn’t a malicious user just set up a new link between these systems? The answer is yes, they can absolutely do that. That is why connecting a new external login to an existing account should be treated as a sensitive action. Remember the missing magic?
A safer process would look something like this:
A user signs in with the external identity provider.
The application notices that an account with the same email address already exists.
Instead of automatically connecting the two, the application asks the user to sign in to the existing account as well. Since this is a critical action, ask them for a second factor as well.
Only then should the external identity be connected to the account.
Dropbox has since changed its process so that a Dropbox password must be entered before access through Lenovo can be established. That is one step closer to the type of control you want around account linking, but in our opinion still lacking some of the modern tricks we should be using.
Govern your federation connections
One detail that stands out in this incident is that the Lenovo connection was described, by themselves, as a legacy integration.
Federation connections are often set up once and then left in place for years.
During that time, systems change. Security requirements change. Identity platforms are upgraded. People leave the organisation. New authentication methods are introduced. But the old trust relationship may continue to exist. This is what we call “shadow IT”
Companies should therefore regularly review federation connections and ask:
- Is this connection still needed?
- Who owns it?
- Which users can use it?
- Which information do we trust?
- How are accounts linked?
- What happens if the connection needs to be disabled quickly?
This type of governance is something we see is lacking in a lot of companies where IAM maturity levels are low
Federation is more than configuring SSO
A federation project can look simple from the outside. Connect two systems, exchange some configuration, test the login and go live.
In reality, the most important, and often most neglected, part is deciding what one system is allowed to trust about the other system.
- Who is the user?
- How do we know that?
- Which information can we rely on?
- How do we link an external identity to an existing account?
- What happens if the external system is compromised?
These are IAM questions, not just technical configuration questions.
This is where IAM expertise matters
At IdentIT, we design and implement federation connections between identity systems.
That can include connections between Microsoft Entra ID, Ping Identity, customer identity platforms, partner systems, cloud applications and custom applications.
Our focus is not only on getting single sign-on to work. We look beyond the technical connections. To the trust two systems are putting in each other.
That means making clear decisions about which users are allowed in, how accounts are connected, what information is trusted, when extra authentication is required and how the connection can be monitored or disabled if something goes wrong. This is taking it from a feature requested by business, to a conversation at a higher level.
We can also review existing federation environments to identify older or risky configurations before they become a security issue.
The Lenovo–Dropbox incident is a useful reminder of an important IAM principle:
A federation connection is a trust relationship.
Getting the login to work is the easy part. Making sure that trust is governed, controlled and regularly reviewed is what makes the connection secure.
