Single sign-on (SSO) gives end-users (usually educators and students) a way to easily log into their learning tool. If you have ever seen a login screen that says, “Log in with Google”, that is a platform that uses Google for SSO. In the case of edtech products and Schoology, SSO could be a button on the product’s login screen that users can click and sign in using their Schoology information. This way the product can provide users a more streamlined experience to access the product without having to juggle another login and password. Using this type of login method also means the edtech developer wouldn’t have to manage passwords and troubleshoot them when users forget their logins. Instead, the edtech developer would just use what Schoology has built.

To provide SSO through Schoology, edtech developers have 2 methods:

  • an API integration or
  • an LTI specification integration.

Method 1: Schoology SSO through API Integration

An edtech product can provide SSO with Schoology by integrating directly to the Schoology API. When integrated, users can start on an edtech product’s login page, and click a "Sign In With Schoology" button. Schoology then prompts the user for a username and password. The product never sees the password the user entered.

After signing into Schoology, the user is redirected back to the learning platform with a code that corresponds to the account. Using this code, the product can ask Schoology for more details about the user, such as personal information, course enrollments, or assignments.

To onboard a learning institution, the product’s implementation team would need to connect with the learning institution’s admin of the Schoology instance to connect their information. This would then “open up” the data pipeline so the product could begin syncing the learning institution’s information.

Schoology gives school admins 2 options for where to authenticate:

  • Schoology's website directly, or
  • a custom domain that users at their school are directed to.

If you haven't planned for these scenarios, you could run into problems when trying to sign in users who need to log in at a different URL. If you haven’t experienced working with OAuth, you could face a learning curve but would be able to get over it. Another, larger issue that you would need to prepare for is how to limit the amount of PII the learning institution shares to limit the company’s liability.

Method 2: Schoology SSO Through LTI

Schoology supports the LTI 1.1 specification (now depreciated by 1EdTech), and the LTI 1.3 specification. LTI-compliant apps are designed to be accessed within a course in the LMS, in this case, Schoology. LTI-compliant apps must be configured by the Schoology administrator so that the teacher and students in the course can access the app. Students and educators can then launch into the application by selecting the tool from the course in Schoology. This launch process creates an iframe, which might not be ideal for every product and user experience.

Another limitation to consider is that the educator has to log in first before the students. The educator’s context is tied to the course and student information, which is only populated into the LTI-compliant app once the educator logs in first. It sounds logical, but in reality, this order of operations can cause a lot of user confusion and false errors. Many times educators and students are not aware of the login order, and sometimes developers aren’t fully aware of this quirk to test their apps properly.

With a Schoology LTI specification integration, SSO is always initiated from the LMS (i.e. students won't visit a website or mobile app to access the resource). After the LTI specification launch, the developer receives a set of URLs that can be used to perform further integrated functions, like grade syncing.

What other Challenges Can You Expect?

There are some other issues that edtech developers may encounter when trying to integrate an SSO solution into their app. Like:

  1. Many apps try to identify users who sign in through Schoology by a user’s email address. Doing this can lead to problems and leave users vulnerable.
  2. Developers may also try to assign a universal role to students, teachers, and administrators in the app based on the user role in Schoology. But Schoology allows users to have multiple roles depending on the context – making roles more complex.
  3. With the LTI specification’s multiple versions, each LMS handles LTI specifications integrations differently – even if the LMS supports the same version. So, an LTI-compliant app for another LMS – like Moodle – doesn't always mean the app is going to work the same way in Schoology.

Updated | 5.8.24

Learn More about Schoology or SSO Integrations

If you’re interested to learn more about these types of integrations, here are other articles we’ve written:

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

Introducing Edlink
Our Mission at Edlink
What is the Edlink Unified API