core:*:* scope
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!
Answers
-
Hi Jason,
This is my understanding as well, although it may be prudent to wait for a response from a D2L representative to confirm as well, given the data access concerns.
You can think of OAuth2.0 scopes as roles/permissions for an application accessing your LMS. The person using that application will also have the roles/permissions set for their account that defines what they are allowed to access. This could go both ways: 1) the application has the scope available, but the user does not have permission to view the data; or 2) the application itself cannot access the data (because it does not have the required scope), even though the user has permissions to view data.
The API routes list the status codes in the documentation. Many of them list 403 Forbidden which points to our understanding—an application could successfully make an API call to the route, but be denied because the person who is authenticated does not have permissions to perform the action.
I hope this helps!
-
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.
-
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.
-
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"
