core:*:* scope

Question

Hi everyone,

I had a quick question.

One of our partners who handles our student advising for one of our programs has requested access to OAuth2.0. They gave us the scope and API calls they were requesting access to. Several of the dropbox/assignment API routes don't have their own scope as most of the tools do, so they're just included in core:*:*.

The core:*:* scope appears to include all other APIs in it that aren't in any other scopes. Just so I'm completely clear, the core:*:* scope does not override a user's role/permissions, correct? Meaning, if core scope included the API scope to access dropbox grades, but the user who authenticates through OAuth2.0 does not include access to dropbox grades, the user can't see if even though the OAuth app's scope included them, correct?

I assume this to be the case, but just wanted to be positive before we give away access to a significant amount of data, access, and permissions we didn't intend to.

Thank you!

Alison.F.745 · Answer

This is our experience as well, the user's role also needs permission to make the call as well as the correct scope. However, we did not need to grant core:*:* for endpoints that did not have a scope listed, we didn't add anything.

We have a simple app that updates users photos, the user/role it is run as has permission to edit profiles. There is no scope listed for the endpoint "POST /d2l/api/lp/(version)/profile/user/(userId)/image" and our OAuth scope for our app is set as "users:profile:read users:userdata:read"

Matthew.T.222 · Answer

I've only used OAuth2 and not id-key pair, and have run in to 403 responses when calling routes that my user account did not have appropriate permissions for. I think as long as your advising partner's account has the appropriate permissions for what they need (e.g. dropbox grades), then granting core:*:* should not grant them access to information they couldn't already access.

Also of note, D2L has been adding more scopes to the OAuth routes over time. This is the list of current scopes/routes that are available for Dropbox. New additions are usually added to the changelog when they are rolled out.

Jason.W.277 · Answer

Thank you. That's what I always thought, but wanted to be absolutely certain. Especially since Valence allows for both OAuth2 and id-key pair authentication (which is what I've always used), that the response codes weren't listed for just the one authentication method.