Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow multiple scopes #7

Open
kilahimm opened this issue Apr 5, 2022 · 4 comments
Open

Allow multiple scopes #7

kilahimm opened this issue Apr 5, 2022 · 4 comments
Assignees

Comments

@kilahimm
Copy link
Member

kilahimm commented Apr 5, 2022

Determine if it's possible to present a user with multiple scopes and all them to self select the permission level granted to GW on their ORCID profile.

@kilahimm kilahimm added this to the m.next milestone Aug 2, 2022
@dolsysmith
Copy link
Collaborator

I believe this is just a matter of specifying which scopes we are asking the user to authorize in the initial ORCID redirect (URL params). So we'd need to prompt the user for that choice on our end.

@dolsysmith dolsysmith self-assigned this Aug 5, 2022
@dolsysmith
Copy link
Collaborator

Some more information about managing scopes.

Here's the scenario:

Let's say a user grants permissions for the read-limited scope. Then that same user, at a later date, grants permissions for the /activities/update scope (without explicitly granting read-limited again). Are these additive? In other words, since the user has granted read-limited already (and assuming they haven't revoked it), will the /activities/update be added onto the former? Or would it replace it?

Answer (from ORCID support):

You would have two separated access tokens: one with /read-limited access and another one with the /activities/update scope. You would need to use those two access tokens separately in order for you to interact with the ORCID record.

Also, each scope is distinct; none includes the others implicitly:

The only scope that is implicitly included in other scopes is the /authenticate scope. This is because we always return the authenticated ORCID iD in all token exchange calls. All other scopes are separate from each other. If you request access to /activities/update only, you won't be able to access read-limited data and vice-versa.

Considerations for our integration

  • We need the capability to store multiple tokens for each user (if we're allowing them to select scopes), since a user may grant permissions for one scope at one point in time and another later.
  • In using the tokens, we should probably return the most recent token associated with a given scope.
  • It doesn't appear possible in the ORCID UI to revoke permissions selectively (to one scope but not the others) when permissions have been granted for multiple scopes.
  • We can revoke access tokens via API, which revoke only the permissions associated with that token (may be be a subset of all permissions). So to give users full control over their permissions, we may need to build out this logic in a UI on our end.

@dolsysmith
Copy link
Collaborator

dolsysmith commented Aug 17, 2022

Further enhancement: implement check to prevent users for authorizing the same scopes they have already authorized, provided their tokens are still valid. (Recommended in ORCID's best practices for integration.)

Oops, duplicate of #4.

@kerchner
Copy link
Member

Currently the "UserId" field in the database is not unique, so storing multiple tokens for each user would not require a change to the schema. We are also storing datetime stamps, so we would be able to retrieve the most recent token associated with a given scope.

However, the scope field is currently stored in the form it's received, i.e. /scope1 /scope2 as a single string. It looks like we may need to parse that out and store separately (in this example, that would map to 2 records). Depending of course on how we choose to implement.

@kilahimm kilahimm removed this from the 1.0 milestone Oct 4, 2022
@dolsysmith dolsysmith changed the title Explore allowing multiple scopes Allow multiple scopes Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants