The Brightspace API provides developers with two Authentication approaches: OAuth 2.0 and our own proprietary Id Key Auth. This Authentication Guide focuses on OAuth 2.0. Please note that we encourage you to use the OAuth 2.0 standard as that is where we at D2L are investing.
Regardless of the Authentication approach, the security best practices outlined here apply.
API Apps provide a very powerful means of accessing Brightspace. The combination of an API App’s information plus a Brightspace user account provides access to the Brightspace API. It is therefore important to keep API App information available to a minimal number of people. Most importantly, keep these pieces of information secure:
- OAuth 2.0 - Client Secret
- ID Key Auth - App Key
Brightspace User Context
Every Brightspace User is enrolled in Brightspace Org Units with a specific Role. That Role’s permissions determine what the user can and cannot do within the Brightspace UI and with the Brightspace API.
OAuth 2.0 Scopes
OAuth 2.0 provides an additional level of control over access to Brightspace through our API. With OAuth 2.0 the Brightspace permissions of the User still apply, but the OAuth 2.0 App being used must also have sufficient Scopes to perform API calls. A list of available OAuth 2.0 scopes is available in our Brightspace API documentation.
Not all API routes have a defined OAuth 2.0 scope. These routes use a special scope named “core:*:*”. We plan to add more specific OAuth 2.0 scopes over time. As we do so, we will continue to support the “core:*:*” scope for those routes. However, it is strongly recommended that Apps update their scope definition to align to the most specific scope values available.
Brightspace API and User Context
OAuth 2.0 Scopes Table
Getting Started With OAuth 2.0 Scopes - FAQ
ID Key Auth - User Authentication FAQ & Best Practices