Scopes Table for LTI Advantage tools that use Client Credentials Flow?

Judit.T.2921

We are developing a tool that is registered as an LTI Advantage and we are using the 'client_credentials' approach to obtain the access token. We also try to call some Brightspace API endpoints (with the authorization header applied).

To be able to call these selected API endpoints, we have to authorize the user specifying the right scopes. These scopes have a URL-like format specified in the IMS Global (1EdTech) standards:  https://www.imsglobal.org/spec/security/v1p0/#h_scope-naming-conventions

Our question is:

Isn’t there a scopes table listing pairs of scopes and endpoints like for projects that are registered as OAuth 2.0 applications and using the 'authorization_code' approach?  https://docs.valence.desire2learn.com/http-scopestable.html

Viktor.H.147

Please note that although both Learning Framework API applications (apps that use our "Valence" APIs) and LTI Tool both use our OAuth2 infrastructure for authentication, including scopes, their access must be managed separately, and there are differences between both styles of integration.

LTI Tools — LTI Tools are integrated using our LTI management user experience. LTI Tools may use the Client Credentials Grant workflow for access to LTI services hosted by Brightspace, as specified in the relevant LTI specifications. Note that while scopes grant access to LTI services for Tools, our LTI Tool management process does not have you request these scopes directly; when you integrate an LTI Tool part of that process has the integrator declare what LTI services the Tool will have access to, and this determines what scopes it can ask to use later.

Also, if an LTI Tool wants to also use our proprietary APIs, then they must register separately. (Note that LTI Tools using LTI services are making the service calls in the calling user context of a pre-provisioned "LTI service user", not as an individual Brightspace user account.)

Learning Framework API applications — app integrations that use our proprietary Brightspace APIs (historically referred to as "Valence" apps) must be registered via Brightspace's "Manage Extensibility" user experience, separate from LTI management. These apps may not currently use the Client Credentials Grant workflow; rather, they must use the three-legged Authorization Code Grant workflow for gaining access to an initial access token/refresh token pair. After this initial provisioning, they can use the refresh token to refresh access ( note however that what they are refreshing is the access token bound to the "calling user context" for which they were originally granted access: the real Brightspace user that authenticated with Brightspace during the initial Auth Code Grant workflow).

OAuth2 Scopes restrict the third-party application's access to both LTI services and particular Learning Framework APIs, separately. Our authentication infrastructure will not provide an access token that mixes these two sets of scopes together — each access token will only grant access to either LTI services or the Learning Framework APIs, not both.

Because of this, people who implement applications that want to use both LTI and our proprietary APIs will need to both:

• Design these apps to separately manage the authentication and access workflows, and the granted credentials as a result of these workflows.
• Integrate them into Brightspace using both integration workflows: admins must separately integrate them as LTI Tools using the LTI management tools, and integrate them as external applications using the Manage Extensibility tools.

Judit.T.2921

Hi Viktor,

Thank you for your long and detailed answer. What you wrote but also other factors got us thinking…

So we are changing our strategy.
We would try out having an ID Key Authorization registration for our API. Do you have any experience with it? Though I guess this is a good starting point:
https://community.d2l.com/brightspace/kb/articles/1165-brightspace-api-authentication-guide-id-key-auth
The LTI Advantage registration, we already have, we’ll use for the frontend.

I think we’ll get back later.

Viktor.H.147

I would still recommend you use the OAuth2 authentication system for your app's use of Valence APIs; enumerating the scopes you'll need and registering to use those scopes puts a lot of careful work up front, but overall the process is smoother and since the LTI-using portion of the app and the Valence using-portion of the app will still be requesting and using an OAuth2 access token in the end, a lot of common code use (including good support from a variety of off-the-shelf OAuth2 libraries) can be had there.

The ID-Key Auth system is bespoke to D2L, deprecated now, and pretty idiosyncratic. We don't recommend its use for new app development.