Account Linking, Redux

Heya,

Account linking seems like a no-brainer. It offers lower friction, higher conversion, and happier users. But is it that easy? Keith Casey offered a great comment on the account linking post I made earlier this month. He points out some things I didn’t address.

Like Keith said, account linking has tradeoffs. With that post, I discussed the benefits and nuances of account linking. But one thing Keith pointed out that I didn’t talk about was the risks of account linking. There are two main risks that he raises. These are real problems and tied to the benefits of account linking.

The first risk primarily affects B2C customers, such as consumers or small businesses. The risk is that if you’re offering account linking to the customer or the end user, you are deferring to an identity management system outside of your control. You have less data and less risk, but less control as well.

This might be Google, Facebook, or WeChat, whatever your end consumer wants. As mentioned before, as an application developer, you get the benefit of lower friction and higher conversion. The user benefits from fewer sources of identity truth. They have fewer systems where they have watch their passwords and account details like a hawk. And they have one place where they can see all the apps they’ve connected to this identity.

The flipside of federating identity is that if a provider goes out of business (unlikely) or suspends that account (far more likely) because their automated systems see abuse, then your user has lost access to their account. For some of these providers, you don’t really have recourse either (other than by posting to social media and hoping). If you copy the users data to your system and offer account reset workflows, that mitigates this risk. But now you are responsible for identity data again.

Even worse, if the federated account itself is compromised, attackers gain access to all downstream applications. As an application developer, an attacker login looks just like any normal federated login. So you won’t know that your users’ accounts have been taken over!

The B2E world faces a different but still significant challenge.

The second risk, primarily affects business to employee scenarios. The risk is that you sometimes have additional security restrictions you need to apply to your application. Depending on the implementation of single sign-on or federated identity, you may not be able to implement them.

For instance, you may want to have MFA required at login, either every time or in certain situations like a new device login. This may not be possible to configure during login. Since the point of federation is that you trust the remote provider, you might have to write some custom code to meet your security needs.

Another security worry common in B2E scenarios is immediate revocation of access. The whole point of account linking with B2E applications is that the employer is the source of truth for identity. Users are provisioned into your application, but more importantly de-provisioned. When an employer revokes access, they want it revoked quickly. With federation, you get into situations where you have multiple sessions that you have to revoke.

Whenever you have federated identity, you also inherit all of the remote identity provider’s security posture. If the IDP has a breach or vulnerability, your application is exposed too. All your data corresponding to all the users who use that provider is at risk.