Custom power-up managing oAuth ClientId and App Secret

Question

Hi
Not sure where to go for the correct answer.
Building our first power-up. It's a much needed integration with Adobe Workfront.

I have enabled oAuth2, this meant setting up an App on our Workfront instance with traditional oAuth2 Client ID and App Secret.

All working, power-up opens new window, grant access, get code, then redirect to get token and refresh token. Return back to Trello with Token and Refresh Token.

Not worried too much about storing either token, the token is only valid for 2 minutes and the refresh token is of no use without the Client ID & the App Secret

However looking at best practices with a power-up on handling the Client ID & the App Secret.

For a one-off private power-up, I can store the Client ID and App Secret server side.

If I wanted to make this power-up public, how to you deal with the Client ID and App Secret?

Another Workfront instance admin would have to set up oAuth2 on their Workfront instance. They then would have their own Client ID and App Secret. How do I get that into the power-up and store it will out risk of reveling the secret.

I know I can use t.storeSecret that will store the secret on the users browsers under the power-ups' domain. But this means the admin needs to share the app secret with everyone so they can enter it for each browser in-use, defeats the object of having it.

I could build a data store on the server side of the power-up and store the client id and secret there but they still have to get the information to the server and then run into GDRP.

How do other developers deal with dynamic Client ID's & the App Secret's?

Thoughts;

Can I use the power-up settings panel, so when a Trello admin enables the power-up they add the Client Id and App Secret. When the settings panel (iFrame) is saved, I could save on the server side.

With the power-up settings, can the data be read by the power-up but not by anyone else. Can you limit who as access to a power-up settings. I know you have private and shared. I want an admin to write it once, but they it be accessible by the power for normal users to allow oAuth2

Thanks
Dean

Alex W_jr9vvs · Answer

@Dean Holmes - I also recommend raising this in the Developer Community instead of the Atlassian Community. This forum is meant for people who have questions about using Trello, not developing on Trello. The Developer Community is more geared towards the questions you're asking: https://community.developer.atlassian.com/

Alex W_jr9vvs · Answer

Hi @Dean Holmes - please add this comment to the ticket you raised with Support. This ticket has already been escalated to our developers as you're asking a question about development, so any replies you have should be sent to them.

Dean Holmes · Answer

They did thanks, however they provided a link just to standard information on how to use t.authorize.

I have the oAuth2 process working, storing session token and refresh token.

Current while under dev, I'm storing the ClientID and Secret server side as we own the servers.

Looking at best method of storing  ClientID and Secret as these are dynamic to each Workfront instance.

The only thing I can think off, is having a settings page;

1: Admin files out 3 fields:
     Workfront Instance URL
     Client ID
     Secret (password field)

2. Store Workfront Instance URL as shared t.set

3. Store Client ID & Secret in encrypted database server side against  Workfront Instance URL as key

First time user uses power up, we look up shared Workfront Instance URL and send with request, we fetch the Client ID  from database server side and start Workfront oAuth2 process.

Subsequent calls we get the shared  Workfront Instance URL, use that again to get Client ID  & Secret from database and use that with members token to get access or refresh token.

Would mean power-up would need to run on our servers.

Indecently we own & operate our own Cloud infrastructure and run a lot of instances in kubernetes clusters. Data is very secure as it's only accessible with in their own structure. However not sure how that would work getting power-up into your market space.

Thanks

Dean