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

Bring OAuth and API key system closer together #1934

Closed
ThiefMaster opened this issue Jun 16, 2015 · 2 comments · Fixed by #4976
Closed

Bring OAuth and API key system closer together #1934

ThiefMaster opened this issue Jun 16, 2015 · 2 comments · Fixed by #4976
Assignees
Projects
Milestone

Comments

@ThiefMaster
Copy link
Member

ThiefMaster commented Jun 16, 2015

Currently we have:

  • API keys: One per user, they grant full access with whatever permissions the associated users have
  • OAuth tokens: Tied to an application, they only grant specific permissions

This requires you to use the full-access API key if you want to use it in a custom application (since not everyone can add new OAuth apps on Indico, and the OAuth flow is not very nice if you don't have something used by multiple users - e.g. drupal feeds on your site).


There is be a much cleaner way, similar to what GitHub does:

  • Users can create oauth-token like keys and select the scopes they are granted
  • Instead of API keys you use these tokens
  • They can be revoked at any time and are usually specific to one external application so if one is compromised you don't have to reset all of them like it's the case with the current api key system

Migration-wise, existing API keys could be simply converted to a token with full permissions.

The only disadvantage I see is that signatures would probably go away. However, considering that OAuth doesn't use signatures either and pretty much no APIs nowadays go through all the trouble of signing requests I think that wouldn't be a problem. At least when HTTPS is being used, which should be the case anyway.


This would obviously be something for once the migration is finished - e.g. 2.0 or 2.1. Personally I'd go for 2.0 if we do this and have time between finishing the migration, cleaning things up, and releasing the version. That way there would be no "big" changes related to this in 2.1.

@DirkHoffmann
Copy link
Member

👍

@pferreir
Copy link
Member

Have my doubts that this can make it to 2.0, however. It's not a trivial change and there are more important things that will have to change already.

@ThiefMaster ThiefMaster removed this from the v2.1 milestone Mar 6, 2018
@ThiefMaster ThiefMaster self-assigned this Jun 30, 2021
@ThiefMaster ThiefMaster added this to the v3 milestone Jun 30, 2021
@ThiefMaster ThiefMaster added this to To do in Release 3.0 via automation Jun 30, 2021
@ThiefMaster ThiefMaster moved this from To do to Awaiting review/merge in Release 3.0 Jun 30, 2021
Release 3.0 automation moved this from Awaiting review/merge to Done Jul 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Release 3.0
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants