Why You Shouldn't Match Users by Email Address Where SSO Is Involved

by Dakota Gordon

SSO is an effective way to get users into elearning apps quickly and easily without spending a massive amount of development or support time. Apps save time by implementing an SSO integration instead of authenticating users through the traditional email and password setup. When apps build an SSO integration, they can rely on the LMS or other educational data system to provide the credentials.

There are a variety of different SSO providers that schools will commonly request. Each provider comes with a number of different pitfalls. But for this context, will focus on one: using email addresses.

When a user authenticates using SSO (e.g. Sign In With Google), the app will try to match the user’s Google email address against an email address that is stored in the app’s database. If a match is found, the app will then log in the user with the matching account.

This doesn’t sound illogical or wild – what’s the problem?

The problem is that developers cannot trust the email address provided to the app by most LMSs and school data sources.

Most LMSs and SISs allow administrators (or even users!) set an email address for the user’s account. Very often, this email address remains totally unverified. The user account is now effectively tied to that email address only because the app said it was.

When you sign into an online learning app using a user’s Canvas account (for example), Canvas informs the platform of the user’s email address. This address could be legitimate, or it could be an attacker trying to gain access to another user's account.

Ok, if this happens, what are the implications?

It’s quite serious, actually. A malicious user with access to any sort of Canvas, ClassLink, Blackboard (etc.) instance could set the user email address to be anything. Their own, their friends, their teachers, even yours – anything at all. Once the bad actor signs into the learning app with this LMS account, the bad actor will actually log in as the user whose email address  the bad actor impersonated.

Depending on how the elearning app works, this could expose developers to any number of security risks from students modifying their own grades, to malicious users even gaining school or product-level administrative access.

Are LTI launches vulnerable, too?

If developers use LTI launch for users to access the app, developers may be vulnerable to this type of attack as well. Again, the LMS is only providing developers with the email address that it knows for the user. It's not guaranteeing that the LMS actually owns these email addresses.

If developers are looking at the provided email address during the LTI launch phase, you are susceptible to this attack. Any user impersonating someone else (by telling the LMS that they have a different email address) will be able to instantly log into their target's account.

Are SIS integration platforms vulnerable, too?

SIS integration platforms like Clever, ClassLink, and GG4L are also potentially vulnerable to this issue. While developers cannot necessarily change data from within these platforms themselves (depends on the platform), when developers integrate, they are simply passing through data from the SISs that the integration is connected to. In a sense, developers are trusting the SIS to provide accurate data – which makes the app as vulnerable as their weakest SIS link. It is unlikely that most SISs verify a user's email address, so this is probably an issue that affects all SIS providers.

To sum that up, just because the app may be able to trust Clever to provide a user's email address, doesn't guarantee that the email address was accurate in the first place.

Does this affect Google SSO?

Probably not. Business SSO providers like Google or Microsoft are reliable to a larger extent because they do typically require some sort of email ownership verification. Although we still do not recommend using email matching, it can be much safer if are only implementing sign-on with major email providers.

Why is this issue so prevalent?

When a developer first implements SSO, it's easy to overlook this problem and assume that the LMS or SIS providers are conducting the same security checks. However, this is not the case, and it’s unlikely to change.

Another fact that developers often overlook is that many LMS platforms can be entirely self-hosted. A developer can jump over into Canvas's GitHub repository right now and have their own Canvas instance up and running by tomorrow.

How do you patch this security hole?

The short answer is: don't rely on email addresses to match users in your database!

Treat email addresses like a person's first name – just another attribute about the person that is getting stored.

What developers should look for instead, is the user's LMS ID, in conjunction with some identifier that represents the system they're coming from. For example, a developer might store a user's Canvas ID joined with the ID of the Canvas instance itself.

At Edlink, we address this problem for our clients by providing a UUID for each user account. Clients rely on this ID to authenticate incoming users, instead of looking at the email address. This ID is stable and it does not run the risk of overlapping with a malicious user coming from a different LMS.

Learn More on Integrations

If you’re interested to learn more about integrations and Edlink’s Unified API, here’re other articles we’ve written:

Set Up a Meeting

Ready to see if Edlink can help you on your integration journey? Email us at support@ed.link to set up a call.