Brightspace supports server-to-server API authentication using the OAuth 2.0 Client Credentials grant with Client Assertion (Private Key JWT). This model lets trusted integrations call Brightspace APIs without user interaction while protecting sensitive LMS data.
To use this feature, you must first create a dedicated Service User for the integration, then register an OAuth 2.0 application that uses that Service User to obtain access tokens.
|
Important: Server-to-server authentication is available only for OAuth 2.0 applications that are associated with a Service User. You must use a dedicated non-human Service User with least-privilege permissions for each integration. For information about creating Service Users, refer to Manage Service Users.
For information about Setting up OAuth 2.0 authentication for developers, refer to Setting up OAuth 2.0 authentication in Brightspace developer documentation.
|
Permissions required
To register an OAuth 2.0 application for server-to-server authentication, your role must have the following permissions:
- Service Users > See Service User Tool
- Manage Extensibility > Can Manage API Applications
Access the OAuth 2.0 applications list
Administrators manage OAuth 2.0 applications from the Manage Extensibility page.
To access the OAuth 2.0 applications list:
- Navigate to Admin Tools > Manage Extensibility.
- Click the OAuth 2.0 tab to view the list of registered applications.
The page lists existing OAuth 2.0 applications and their grant types.
Register a server-to-server OAuth 2.0 application
To register a new OAuth 2.0 application that uses the Client Credentials grant with client assertion using a signed JWT:
- On the OAuth 2.0 tab, click Register an app. The Register an Application page opens.
- Under Grant Type, select Client Credentials.
- In Application Name, enter a clear name that identifies the integration. For example, Server-to-Server API Client or the name of the vendor service.
- In JWKS URL, enter the HTTPS URL that hosts the JSON Web Key Set (JWKS) for your authorization server. Brightspace uses this URL to retrieve public keys for verifying signed client assertions.
- In Scope, enter the scopes the application is allowed to request. Scopes must use the format
group:resource:permissions. Separate multiple scopes with spaces. The group portion cannot be a wildcard value.
- In Access Token Lifetime (seconds), enter the number of seconds that each access token should remain valid. The minimum is 1800 seconds (30 minutes) and the maximum is 72000 seconds (20 hours).
- Under Service User, click Add Service User and do the following:
- In the Add Service User dialog, search for the Service User you previously created for this integration.
- Select the Service User and click Add
- Review or enter a Description that explains the purpose of the application and the system it represents.
- Select I accept the API Developer Agreement.
- Click Register.
The OAuth 2.0 application appears in the applications list with a Grant Type of Client Credentials. From this list, you can confirm that the application is registered and remove it later if needed.
|
Note: Registration in Brightspace completes only the platform side of the configuration. Developers must also configure their authorization server to issue signed client assertions that reference the registered application and its JWKS URL.
|
Next steps for developers
After the OAuth 2.0 application is registered, developers can begin using it for server-to-server API authentication.
- Configure the external authorization server to sign a JSON Web Token (JWT) with the private key that corresponds to the public key in the JWKS URL.
- Implement the OAuth 2.0 Client Credentials flow with Private Key JWT to exchange the signed JWT for an access token from Brightspace.
- Call Brightspace APIs using the access token in the
Authorization: Bearer header.
|
Important: The permissions available to API calls are determined by the role and permissions assigned to the Service User that is linked to the OAuth 2.0 application. Follow least privilege practices and grant only the permissions required for the integration to function.
|