Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Custom power-up managing oAuth ClientId and App Secret

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?


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


1 answer

0 votes
Alex Waite Atlassian Team Jan 27, 2022

Hi @Dean Holmes - I can see you already raised a ticket about this internally with Trello Support, I believe they are in the process of answering you there. 

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.




Like Alex Waite likes this
Alex Waite Atlassian Team Jan 27, 2022

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.

Alex Waite Atlassian Team Jan 27, 2022

@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:

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events