DEV Community

Mitch Pomery (he/him)
Mitch Pomery (he/him)

Posted on

The dangers of choosing the wrong identifier for your users when federating logins

Preface: I was going to title this something along the lines of "Twitter's username clean up is dangerous", but I felt that made it sound too much like what twitter was doing was the dangerous part, and not that other applications failing to follow good practice puts their user data at risk, regardless of what twitter is doing. I also started writing this and then promptly forgot about it for 8 months.

If you haven't seen what twitter did, they removed inactive accounts to free up the usernames. On top of the the issues that others raised with this, freeing up twitter handles made it possible for someone to potentially get access to data that is not theirs.

There's a lot of maybes there. I don't think this has happened, but it is theoretically possible. It is not because of a mistake that twitter has made. It is possible because people changing usernames could uncover issues where a third party application is not linking accounts from twitter as an identity provider correctly.

Example

If you use twitter as an Identity Provider for your application, you have to use a piece of information twitter gives you to link between a twitter account and your application. If you use their twitter username (or email) as this key between your user will experience issues if they change it. If someone else starts using a previously used twitter handle they also gain access to the old users information in your application.

Instead of using a username or email address between you application and an identity provider, which could change, you should look at a field that can't change. If you are using OIDC, you should use the subject claim (and other claims that don't change).

If you think that users information doesn't change, between starting this blog post 8 months ago and finishing it, I lost access to data in one application because I changed the email address I use for Facebook.

Top comments (0)