1. Using an email address to identify students

In many products, users are identified in a database through email addresses. This is a bad idea, especially for products integrated with LMSs. Email addresses that are attached to users in an LMS are typically unverified. Depending on how the LMS is configured, an individual's email address can be changed by an administrator or even by the user.

This means that a user with email-changing access in an LMS can change their email address to anything. For example, a student could change their email address to match that of the teacher. If a product is relying on the user's email to identify, the malicious user could sign into the product with the user’s LMS account. Once signed in, the malicious user can log in on the product as an impersonated user.

This can present a huge security vulnerability when implementing SSO through an LMS. The easiest way to avoid this problem is to simply not match users in a product’s database to LMS email addresses. The address should only be an attribute of the user's profile, like a name. Instead, developers can use the user's Canvas ID joined with the ID of the Canvas environment. This way, products will uniquely know each user from the LMS that is listed in its database.

2. Not every LMS supports the LTI standard in the same way

The LTI standard is supported by several major LMSs. One of the biggest benefits that LTI touts is the ability to incorporate an LTI-compliant app (or “tool”) into any LMS (or ”platform”) that supports the standard. Conceptually, if a developer integrates with the LTI standard for one platform, a tool will be compliant for all others. Unfortunately, this is rarely the case.

Tools generally support one of the 3 major specifications of the LTI standard: LTI 1.0, LTI 1.1, and LTI 1.3 with LTI Advantage specifications. The most recent version of the LTI specification is 1.3 with LTI Advantage. However, not all major LMSs support the LTI standard. Google Classroom and Microsoft Teams don't support the LTI standard at all. Thus, simply having a tool won't be enough if the school’s LMS doesn’t support the standard.

3. Building integrations is 1 step. Managing integrations is a whole other animal.

Writing an integration is not enough. There are other considerations developers should think about when users authenticate into edtech products via an LMS.

For example, each LMS has a different way to treat user properties, such as assigned roles. In some LMSs, like Google Classroom, a teacher in 1 class can be a student in another. A unique instance like this could contradict how a product organizes these properties. Some LMSs don't require email addresses. What would a product do with these users then?

Additionally, how does a product determine which users from a school should have access to it? If only a specific school at a district or section of classes has purchased access, how does a product restrict other users from the same LMS from interacting with the product?

These are the types of questions developers need to ask when designing the architecture of their LMS integrations. There's not a “right answer” to any of these, but not thinking about these questions beforehand can cause serious delays in a developer’s implementation.

4. Onboarding schools can be challenging

A hard part of getting schools to adopt a platform is to persuade school admins to complete the integration. Many types of data integrations are not straightforward and can take hours out of a school admin’s day to complete.

If developers don't make the process easy for administrators, it could cause delays in getting teachers and students onboarded to products – diminishing the user experience. It can also be difficult or confusing for admins to reconnect or correct integrations for updates, configuration changes, or accidental disconnections.

Integrations typically require exchanging sensitive data, such as LTI and API secret keys. These keys can give third parties the ability to read and write to certain endpoints in the school's LMS. If the product doesn't have a secure method for school administrators to exchange keys with a product and store them securely, the exchange could expose the admin’s LMS to serious danger.

Read More on Integration

Here are other articles we’ve written on building integrations to help you on your journey:

If you're looking for a partner who can help guide you through developing LMS integrations (like these), then let’s introduce ourselves. We’re Edlink!