Brightspace’s developer platform authentication requires you to make every API request in a calling context from which the back-end service can determine
What client application makes the call
What Brightspace user is employing the client app to make the call
In the calling context, you provide an authentication token to assert your ability to make the API call on behalf of that user. To get started, you need to follow these four general steps to gather all the resources you’ll need to be able to provide those authentication tokens with each API call your app will make.
Register your application¶
By using the Brightspace Manage Extensibility tool, you can register application with the Brightspace OAuth2 authentication service. Your app will use its Client ID as a public “name” to uniquely identify itself to the Brightspace Authentication Service later when requesting authentication tokens.
Create an LMS test account¶
Every Brightspace API call happens within a calling user context, and the LMS will limit the functionality it extends to your call depending upon the permissions that user would have logged in to the LMS and using through the standard browser interface.
Accordingly, you should ensure you have an appropriate range of LMS user accounts available to you for testing.
If your app will be used only by students, then you only need to have one or more student-role accounts to test with.
If your app will be used by instructors, you’ll need instructor-role accounts as well.
If your app’s functionality is special purpose or administrative in nature (perhaps as an automated server maintenance process or the like), then we recommend that you create an LMS “service” account to pair precisely with your application, and grant that service account the exact set of permissions your app will require. (Use the standard deployed user roles permission sets as guides to which permissions your app may need.)
You will need to know the username and password for all the accounts you want to test with (in order to go through the authentication process that prompts the LMS to send you back the appropriate authentication tokens for each user).
Choose a dev environment¶
We designed the Brightspace API to be platform-neutral and based on commonly supported software standards and practices for web-services-based software development such as OAuth2 and the specific use of the HTTP transport and its verbs in a RESTful manner.
For assistance in developer resources beyond the scope of this documentation, we provide links to a number of developer tools and resources.
As Brightspace’s developer platform is primarily an open-source effort, the community may have contributed additional tools and resources to assist you with development in your environment of choice.
Authenticate with your LMS¶
Every API call your application makes must carry authentication identifying the Brightspace user authorizing you to make the API call on their behalf. The Brightspace API makes use of the Authorization Code Grant workflow specified in the OAuth2.0 standard to request an authorization bearer token.
For more detailed information on how Brightspace makes use of OAuth2.0, you can read our authentication topic.