nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Service-to-service authentication?

Richard.R.305

We want to automate some processes using the Brightspace API, without the need for a human to log in (because the automation process will be running on a server).

Does Brightspace have a process for service-to-service (S2S) authentication? To reiterate, we need to integrate with Brightspace's API without user interaction, using something like the client credentials OAuth 2.0 flow.

I can authenticate and get an access token if I log in as a user, but I can't find any documentation on how to authenticate machine-to-machine.

Thanks,
Richard

Find more posts tagged with

APIs

Accepted answers

All comments

Chris.S.534

Hi Richard,

Currently all applications using the Valence APIs require explicit user consent to make API calls and therefore can only use the three legged workflow requiring a Brightspace user to log in.

However we do support a “service user pattern” for application integrations that are intended to be administrative scripts, middleware development and so forth:

Create a service user/role combination to associate with your application that has the permissions the application/script needs.
Login manually as this user to go through the workflow to be able to provision the application/script with credentials; the credentials need to be stored securely for/with your application.
For OAuth2: the credentials in step 2 will come with a short-lived access token and a longer-lived refresh token (one use); the app will then need to be designed to, on a regular basis, use the refresh token workflow to ask for a new access token and refresh token combo — unlike the step 2 request, the refresh token workflow can be done directly with Auth service and needs no user in between. The initial access token request is three legged and returns an access token and one-use refresh token; the refresh token workflow is two legged and trades that refresh token directly in for another access token and one-use refresh token.

This is also covered in the following resource, https://community.brightspace.com/s/article/How-to-get-started-with-OAuth-2-0 related resources are also available from the linked resource.

Hope that helps!

Richard.R.305

Hi @Chris.S.534

Thanks for your reply! I implemented this approach the other day, but it appeared that the refresh token expired overnight (without ever being used to retrieve an access token). Maybe I was wrong.

If a one-use refresh token is not used for, say, a weekend, does it expire?

Thanks,

Richard

Chris.S.534

Hi Richard,
Apologies for the delayed response, the typical recommendation is, depending on the refresh workflow and if your application runs periodically, is to have a way of “keeping itself alive” by ensuring it does the refresh token workflow before the expiry time hits.

The access tokens are short-lived and can be reused until they expire (minutes/hours), the refresh tokens are long lived but single use (days/weeks). See https://docs.valence.desire2learn.com/basic/oauth2.html#registering-using-oauth-2-0

Hope that helps!

Jasmine.J.394

Hiya,

So, would the user need to re-authorize every time the refresh token expires?

Mike.S.974

Hi Jasmine,

No, you don't need to re-authorize. Just use the new refresh token after every refresh, you can only use the refresh token once.

Jay.G.3889

This solution is not ideal. Using purely refresh tokens and having to create some sort of keep-alive functionality because you don't allow an automated service to fetch a brand new token is not typical integration practice. We have all our D2L content loaded real time from our SIS using your APIs and have been using the older ID KeyAuth solutions to perform server-to-server calls since 2016. I was just looking to update all our automated integrations away from the older ID KeyAuth to OAuth2, but I don't want to use this kind of approach. Please consider incorporating Oauth2 Client Credentials flow in the future. It's designed exactly for this.

Martin.D.2741

Any news on this? We are starting to create integrations and would appreciate a OAuth2 Client Credentials flow very much. The suggested way using expiring refresh tokens doesn't seem like doing it the right way.

Julia.P.6519

Hi @Martin.D.2741,

Thanks for reaching out to the Brightspace Community! At this time, you will need to use a refresh token and establish a path for acquiring and setting a new refresh token every 30 days. We hear your point about wanting an alternate workflow to achieve this and have communicated this request to our product team.

While Q2 doesn't list planned changes for extensibility, keep an eye on the Product Roadmap this summer as we announce new planned changes for areas of the platform including extensibility. Thank you!

Randall.S.394

Now that the Service User has been released, shouldn't this now be possible? I can't seem to find any documentation on how to use the Service User with OATH2 applications.

Niccolo.C.4346

Hello Randall,

Yes. Brightspace now supports server-to-server authentication for API integrations using OAuth 2.0 Client Credentials grant with Client Assertion (Private Key JWT).

Brightspace documentation states:

“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.”

Documentation: Register an OAuth2.0 application for server-to-server authentication - Brightspace

The same article also notes that server-to-server authentication is available only for OAuth 2.0 applications associated with a Service User, and that a dedicated non-human Service User should be used with least-privilege permissions.

Brightspace also documents Service Users as non-human identities designed for machine-to-machine workloads. The Service Users article states that Service Users and OAuth 2.0 Client Credentials with JWT Client Assertions “enable secure access to APIs without user prompts, browser redirects, or refresh tokens.”

Documentation: Service Users and server-to-server authentication for Brightspace - Brightspace

At a high level, the documented setup is:

Create a dedicated Service User.
Assign only the required org unit access and permissions.
Register an OAuth 2.0 application with Client Credentials as the grant type.
Provide a JWKS URL.
Configure the required scopes and access token lifetime.
Link the Service User to the application.
Exchange a signed JWT client assertion for an access token.
Call Brightspace APIs using the access token in the Authorization: Bearer header.

The developer documentation also confirms that Client Credentials applications use JWT client assertions to identify themselves to the Brightspace authentication service.

Developer documentation: OAuth 2 authentication — Developer Platform (June 2026)

This is the documented path for machine-to-machine Brightspace API access and avoids the older refresh-token keep-alive pattern used for delegated user-based OAuth flows.