Brightspace supports two different SSO methods that apps can use to sign users into Brightspace: SSO through the Brightspace API (OAuth 2.0) and SSO through LTI launch.

What to Know When Getting Started With Implementing Brightspace SSO

D2L (company) requires edtech developers who want to integrate with Brightspace to register for a Brightspace developer account. Once a developer account is registered, the developer can use the Manage Extensibility tool to register the third-party app. The developer will also use this tool to retrieve OAuth 2.0 credentials (used specifically for SSO). The Manage Extensibility tool is required to create any Brightspace application. Developers can use SDK packages that are provided by D2L to create development environments for testing.

Method 1: Brightspace SSO Through API Integration

Brightspace can facilitate an SSO integration through the Brightspace API. The Brightspace REST-like API implements OAuth 2.0 to authenticate users. With this style of integration, users can start on a third-party app website and click a "Sign In With Brightspace" button. Brightspace will then prompt the user for a username and password (if the user is not already logged into Brightspace). Third-party apps never see the password the user entered.

After the user signs into Brightspace, the user is redirected back to the initial app website with a code that corresponds to the user’s account. After exchanging this code, the app’s website can ask Brightspace for more details about the user, such as:

  • The user’s personal information,
  • The user’s course enrollments, and
  • The user’s homework assignments.

Brightspace requires users to log into the Brightspace environment specific to their school. An app’s "Sign In with Brightspace" button must direct the user to sign in at the school’s custom Brightspace domain.

Doing an SSO integration through the Brightspace API is also the first step to developing deeper integrations. Once a user is authenticated by Brightspace, an app then has the ability to enact functions in Brightspace on behalf of a user, like gathering a list of the user’s courses or sending grades back to the user’s gradebook in the LMS.

It's important to keep in mind that there are several versions of Brightspace API. Some of these versions overlap and some are only supported in certain versions of Brightspace. This can create issues if developers are working with multiple schools that are running different versions of Brightspace, as developers have to make sure that your API calls are valid for each instance.

Method 2: Brightspace SSO Through LTI

Brightspace supports LTI 1.1, LTI 1.3, and the LTI Advantage services. LTI apps are designed to be accessed within a course in the LMS. LTI apps must be configured by a teacher or administrator so that students in the course can access the app. Students and teachers can then launch into the application by selecting the tool from the user’s course in Canvas. The process of launching the tool will let the app verify the user's identity and grant the user access.

Signing in will always initiate from the LMS (i.e. students won't visit an app’s website to access the resource). After the LTI launch, the developer receives a set of URLs that can be used to perform a limited set of functions, like grade syncing.

Why Implement SSO with Brightspace?

By implementing Brightspace SSO, third-party apps allow admins at the schools to manage accounts and passwords through Brightspace rather than the app. This means developers don't have to build or manage a database containing sensitive passwords. Since tech admins are responsible for managing Brightspace passwords, developers won't receive as many support tickets from users who are having trouble figuring out how to sign in.

By building SSO solutions into the app, developers will also be able to build deeper integrations (think course syncing and grade passback). In fact, once a user is signed in with Brightspace developers can build upon almost any functionality that the user account has access to.

SSO challenges in Brightspace

There are some issues that app developers commonly encounter when trying to integrate an SSO solution into their platform.

Don’t use a user’s email address to identify users who sign in through Brightspace. Doing this can lead to unforeseen problems and leave users vulnerable.

Don’t assign universal roles to students, teachers, or administrators based on roles within Brightspace. Many LMSs, including Brightspace, allows users to have multiple roles depending on the context.

LTI integrations aren’t handled the same way across LMSs. If a developer wrote an LTI app for another LMS, like Moodle, doesn’t always mean the app is going to work the same way in Brightspace. Some more trouble can be found if a developer is converting a mobile app into an LTI-accessible resource, too.Be knowledgeable of all of the different versions of Brightspace. Sometimes, large schools and universities may run different versions of Brightspace on the school’s in-house servers. Others may use a club service, like Brightspace Cloud. So, an API or LTI app that works for one district's Brightspace environment might appear or work differently in another's.

Read More on D2L Brightspace

Here are other articles we’ve written on D2L Brightspace to help you on your integration 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!