[Feature Request] Galaxy OAuth2.0 Provider / Scoped API Keys

[hexylena]

I'd like to add see OAuth (or more simply scoped API keys) added to Galaxy

This would include implementing application specific API keys, with application specific permissions that the user can select amongst. Some scopes might include things like:

• histories
  • read, write
    • read/write any history
  • read('name'), write('name')
    • read/write a history with a specific name
• datasets
  • read
• tools
  • list
  • run
  • run('id')
    • run only tools with id==id.

https://oauthlib.readthedocs.org/en/latest/index.html looks promising.

User stories

1. As a user, I want to be able to grant third-party applications access to my data without providing them my password or granting access to the whole instance.
2. As a user and administrator, I want to see which applications have access to which data and manage them.

My Use Case

I was thinking about JBrowse/Apollo plugins and how I really wouldn't want to give my galaxy API key to a random JBrowse server which might store it and do nasty things. Thus, OAuth is the obvious solution.

I'd love to be able to:

1. visit a JBrowse site
2. Click "blast this protein in your Galaxy"
3. Enter my server URL
4. Be redirected there
5. See a form informing me that JBrowse is requesting permission to access the tools upload, and blastp, and create/list histories.
   • If there was a permission they requested which I didn't want to allow, I should be able to un-check it, at the risk of my request failing
6. Be redirected to JBrowse, they receive a token (somehow) which lets them submit the blast jobs on my behalf, and display the results when done.

If they store the token and re-use it (in good faith) for future requests, it isn't the end of the world.

Implementation Note

If the user has added OAuth applications, they should see a button near by the disk usage which lists a count of # of recent OAuth requests since their last session. Upon clicking it, they should go to a page which lists all of their authorized applications, and shows a detailed list of requests those applications made on their behalf. The intention here is obviously to let people kill applications which are abusing the API.

[enuggetry]

+1 this.

[ihh]

And another +1 from me!

[fikipollo]

+1 sounds great!

[fmareuil]

Another +1! :)

[hexylena]

from @bgruening in issue #13737 copied here due to additional use cases + nice screenshots

It would be nice if we can provide more fine-grained API access to certain features.

Use-cases:

• a user wants to give another user read-only access to the account
• a user-support role should be able to debug user sessions, but not be able to install tools etc.
• automatic tool installation bots do not need access to data and user accounts
• if we have a notification system in place it would be nice if our support and outreach people can notify users, without having admin access

GitHub personal access token page:

GitLab UI:

[hexylena]

Adding another use case: "Login with Galaxy"

We are discussing adding a system to the GTN whereby users could track which tutorials they've done, and we'd love to offload the authentication to Galaxy. I.e. have a button of "Login with Galaxy {EU,AU,US,etc}" that redirects the user to the appropriate Galaxy where they login, and are re-directed back to the GTN, and the GTN receives account information and a scoped token that lets the user do whatever actions they checked (or not.)

[nuwang]

@hexylena That sounds like a nice idea. My personal view is that any implementation needs to figure out a way to delegate this to an auth-provider like keycloak or auth0, and avoid touching Galaxy as much as possible.

[hexylena]

Another use case for this: PWDK, like PTDK but using a workflow invocation (which currently aren't shareable/able to be made public)

Users would be able to "Login with Galaxy", we would request a scoped API key that would just let us read their histories/workflows/workflow invocations, and then we could pass that API key to planemo to run it for them (which remains a challenge for more non-technical users), and provide them the result. We don't need (nor want) a full account API key, in this case it would be best if it was also limited to 1h to limit long term exposure risk.

@nuwang I think my main issue with that is many of these cases would benefit from integration into galaxy, mostly for the scoping. Scoping which resources they need to access (e.g. limit only to one history the user selects, like the android file picker, or limit to all histories, or just pages or just datasets, etc. Many use cases don't need full-account access.), and for how long that access should be allowed, and then returning a Galaxy API compatible API key that we can use on their behalf (to take advantage of the existing bioblend/etc ecosystem.)

[mvdbeek]

which currently aren't shareable/able to be made public

As a side note: access permissions are derived from the history of the invocation, so if you share or publish the history you can access the invocation, e.g. https://usegalaxy.org/workflows/invocations/84e15596bd4fc608?from_panel=true

[hexylena]

oh! that's fantastic news, thanks @mvdbeek, that's very useful news for us

[mvdbeek]

It's in dev though (#18707, #18746), and I've just applied it to the usegalaxy branch