API Key Access to RetroQuest

[dspainte]

Feature Request

For context, I'm working on a slack integration that uses the RQ Api to get all the open action items and send reminder messages to slack.

Currently the RetroQuest API requires a board name/password in order to authenticate. This requires that any integration (like a slack bot) would have to also be provisioned with these parameters, and would have to be configured/updated every time a new board is created.

As an alternative, could we implement API-level authentication? The simplest thing would be an API key, but we could also look at Oauth's client credentials.

Notes

If we were to go down this route, is global access a concern? A slackbot, for example, without some kind of controls, would have access to all of the data in a given Retroquest instance by default. If we introduced some type of authorization based on boards, though, we don't really get any value from doing this, as any integration would have to provide a way for users to specify what boards it has access to, in which case we could just continue to use board name/password that we have now.

Thoughts on this?

[LowBudgetMan]

I think that making access a possibility for other APIs is a good idea. How would the provisioning work for getting an API key? Would anybody be able to get a id and secret for any board they want or should we start worrying about access controls? Or maybe somewhere in between? It'll be interesting to see how we can balance the inclusiveness and anonymity of a team-based account with API keys / credentials.

[ehei]

That's an excellent point! Overall, I'm for API access, and am down to commit some time to it. What the keys give you access to and how to generate them - maybe allow creation of boards via API as well, then those created with the API and therefore a key have access to those boards? Could also have a way to ask for permission to access via the API, or maybe tie key generation TO the boards themselves. So you could go to a board, generate a key, and/or enter a key (or secret?) to allow access?

[Crouchsnap]

I'm not interested in providing global access to the content of boards to anyone. If providing a key for a specific board is a meaningful improvement, sure, we could do that, but one that gives access to all boards is detrimental to the privacy necessary for effective retrospectives. I think a lot of the value RetroQuest provides is in the anonymity it gives to individuals and the private space it provides for teams to hold retrospectives away from anyone not specifically invited.

However, these are my feelings, and if there's evidence that RetroQuest is being used in ways that don't require the same level of privacy maybe we could fork the project.

[dspainte]

Yeah, I certainly want to respect the anonymity of Retros as well. I think that's an important component of this tool. That principle eliminates self-generated apikeys that are globally scoped for sure.

I'll try to enumerate some options that different people have proposed here:

1. Go to a board in the web UI and generate a key (for that board) via the settings
   • This would allow us to avoid forcing third party integrations to take & cache real board passwords - instead they would cache the board name and key, but the key is really just a proxy for the password at this point
2. We support "global" api keys that can see all data, but only give key access to developers/applications we trust
   • This wouldn't be very self-service for other engineers, and it still entails some risk that data that should be anonymous is not.
3. We allow "sign in with RetroQuest" to give third party integrations an option to redirect to Retroquest and let the user sign into a board, and then get the token back. This key or token has access to the board that was signed in to.
   • This seems a bit complex and I haven't thought too deeply about it. We'd have to provide longer lived tokens too, otherwise people would constantly be signing in when tokens expire.
4. For now, we do nothing with api credentials and force any third party integrations to cache board passwords
   • This is the simplest thing that could work. Caching board passwords is the main downside.
5. We allow API access, but only to boards that have been created with that same API key.
   • This seems like it might involve some significant changes in the way we understand the ownership of boards, etc. It would also force anyone who wants to use third party integrations to create their board through that third party integration, which seems odd.

I think of these options, I like 1 and 4 the best. I'm intrigued by 2 but a bit concerned about the anonymity aspect.

Thoughts?

[devguy22]

I'm interested in option 3 so a 3rd party app can leverage RetroQuest's userbase and contribute thoughts/action-items/etc from outside RetroQuest. However, it might not be the best option for your particular use case, as the token expiration situation is limiting.

[dspainte]

Yeah, I think option 3 is interesting, but I don't know if we really have any use cases for it considering it doesn't seem to fit my use case.

Is anyone opposed to option 4? Or any opinions on 1 vs. 4?

[RandomAshes]

This conversation should be moved to discussions