What is Single Sign-On?

Single sign-on (SSO) is a top integration feature for edtech applications. This feature lets users of third party apps pass through the authentication process of different platforms (think LMSs like Google Classroom or Schoology). When this succeeds, the user can login with one-click to the third-party app.

5 Tips for SSO Integrations

  1. Users can come from many platforms
  2. There’s more than one way to implement SSO, even for the same platform
  3. Matching users to schools and/or districts can be tough
  4. Some systems need both developers and school admin to configure the integration
  5. Weigh the cost of buying vs. building an SSO integration

Users can come from many platforms.

Many websites offer different methods for users to authenticate through SSO (e.g. supporting logins through both Google and Facebook). This allows users to sign into a third-party app regardless of platform the user primarily uses. The same concept holds true in edtech. There are a variety of platforms that schools use that support SSO.

All of the major LMSs allow external apps to provide authentication through the app’s SSO methods. Additionally, schools may want apps to provide SSO options through SIS-integrated portals (e.g. Clever, ClassLink, etc.). The more options edtech developers provide to sign into third-party apps, the more likely the app will be able to meet the needs of any school that it wants to work with.

There’s more than one way to implement SSO, even for the same platform.

Most K12 and high education LMSs provide multiple ways for apps to authenticate users through their platforms. The primary ways these platforms support SSO is through their APIs or through the LTI® standard.

Take Canvas for example. Through the Canvas API, edtech developers can implement SSO integrations. Developers also could build a Canvas LTI 1.3 integration for SSO, too. Either way, having both methods help third-party apps stand out. So when schools have preferences about which SSO method they want, third-party apps – who can meet these requests from school RFPs – get to leap ahead of their competitors.

Matching users to schools and/or districts can be tough.

While many LMSs allow apps to see which school or district a user is coming from, not all do. For example, Google Classroom does not have the concept of organizing users by distinct schools, but rather Organizational Units (OUs). OUs are rarely organized by schools. So it can be extremely difficult for developers to determine where a user is coming from when the user signs into the app. If a developer isn’t prepared to handle these users, building the integration may leave the app in a bind.

Some systems need both the developer and school admin to configure the integration.

Several educational data systems require administrators to perform certain tasks to get an SSO integration up and running. For example, Canvas and Brightspace administrators must create and securely transmit developer keys to an app’s development team if the app team wants the app to be able to provide SSO and other integrated functions. To do this properly, developers should provide detailed instructions to administrators and a secure method for the admins to send the developer key IDs and secrets.

Weight the cost of buying vs. building an SSO integration.

SSO generally works the same across platforms, but building SSO integrations into third-party apps can take a decent amount of time and effort. Each educational data system has its quirks, and not all platforms support authentication through the standard OAuth 2.0 workflow. Dive further into the costs associated with building an integration in-house.

Read More on SSO

Here are other articles we’ve written on SSO 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!