Best way to authenticate with an internally developed tool from within Brightspace

Question

Wondering if there's some quick advice on this:

I am needing to reach out to third-party APIs with some internally made and managed tools that are currently loaded as widgets. They talk to proxies I've built that reach out to the APIs because they are application level not built for browsers. On the inside I am also using the Brightspace API but currently just lifting the token for that out of the browser as "undocumented" elsewhere. Though I probably will want to upgrade this soon, but all the Brightspace API calls come from the user's browser not the proxies or anything.

Currently, for development, the keys are hardcoded into the javascript environment in the source code of the widget. I don't want to embed any keys to access the proxies in the code itself and was originally hoping I could piggy back on the current session Entra ID or OIDC session to authenticate with the tool so it's not just sitting there open on the internet. But that would mean the widget would need to ask Brightspace for the key.

The chatbots keep trying to tell me I need to make my tools implement LTI 1.3 but I am wondering if there is something more scrappy, lightweight and simpler that is still secure.

Station.G.794 · Answer

I am not sure that it does:

Register an OAuth2.0 application for server-to-server authentication: "This model lets trusted integrations call Brightspace APIs without user interaction while protecting sensitive LMS data."

Introducing Service Users and server-to-server authentication for Brightspace: "Any API call made using that token is performed with the permissions of the associated service user."

These statements seem to imply that granting the tool access to Brightspace API. But the goal is different, we want to verify the user (using the tool from within a Brightspace widget or page) is currently logged in to Brightspace. The tools rely on the users access to the LMS so as to limit access on the public internet. Is it possible to use the OAuth2.0 the other way as well? For all intents and purposes I'm basically looking to stash an environment variable or secret in the Brightspace instance that has the API key for the external tool so they aren't hardcoded into the widgets and pages.

I hope that clarifies it. Honestly I am still trying to form a complete picture of the pieces involved, but we already have brightspace access and are within brightspace the "app" is pulled in via javascript cdn in the widget or page.

It seems like if we were to go to LTI we might actually lose the local in browser Brightspace session and then need to put all the Brightspace access into the tool itself, right?

Nikhil.P.7500 · Answer

@Station.G.794 Hi Station,

Thank you for reaching out to us on the Brightspace Community site.

I believe the requirement you mentioned should be supported by using the newer Server-to-Server Authentication method.

More information about Server-to-Server Authentication can be found in the articles below:

https://community.d2l.com/brightspace/kb/articles/33609-introducing-service-users-and-server-to-server-authentication-for-brightspace

https://community.d2l.com/brightspace/kb/articles/33526-register-an-oauth2-0-application-for-server-to-server-authentication

https://community.d2l.com/brightspace/kb/articles/34318-service-users-and-server-to-server-authentication-for-brightspace

Please review the documentation and let us know if the newer Server-to-Server Authentication method would work for you.

Kind regards,

Nik