Moving away from per-installation shared secrets for apps

Announcements
, ,
21

Hi @dzagorovsky ,

Thanks for checking in. The subsequent phases of the migration were put on hold in favor of other initiatives. This means that although most marketplace installations now share a secret per-app (with some exceptions such as installations on dormant instances), the secret continues to be sent in the lifecycle payload, and frameworks continue to store secrets per-installation.

A lot has happened in the intervening time, including Forge, and this announcement by @HeyJoe that:

We’re working to combine Connect and Forge into a single, unified development experience that enables self-hosted and Atlassian-hosted apps on a single platform.

We’re making plans to finish the shared secret journey by way of this unification work, with signing of the initial install hook and dropping the sharedSecret field being a part of that plan (among other things). We expect to have a bit more news to share and opportunities to test out and give feedback on what we’re doing soon.

Thanks again,

James Hazelwood
Ecosystem Developer

3 Likes
22

@jhazelwood new APIs are cool, but please don’t break how current things are working, that we will not need to change all our current apps

23

Hi @jhazelwood,

Thanks for the detailed response, can you please clarify this exception aspect: Provided we are implementing and publishing a new Cloud app from scratch, is it safe to assume that all customers will only ever sent the shared secret so that a new custom Connect framework would not need to account for the secret in the lifecycle payload anymore?

Cheers,
Steffen

24

Hi @sopel,

Good question. We’ve got almost all the ingredients required to be able to disregard the secret in the payload but there are still a couple of complications that prevent me from recommending that. Secrets can still get out of sync because if a secret gets rotated (e.g. due to being leaked) it’s a matter of hours before all installations pick it up. You could store a new global secret + an old global secret as a fallback, but then the fallback would continue to work for all installs until you turned it off, which is not ideal if you’re rotating off the old secret due to a potential leak. Taking this along with the fact that we haven’t done much testing of this approach ourselves, I feel like the risk outweighs the rewards. If you’d still like to spike this approach, though, please let us know how it goes!

Thanks,
James

2 Likes
25

I am bit confused right now. We have one app which has same sharedSecret for all hosts.
However, there is another app I am currently testing. It gave me different sharedSecret values when installing it in two instances via DEV mode (i.e. by providing descriptor file).

So sharedSecret is same in most cases but can differ in some?

26

@chhantyal the secret is per-installation when you provide the descriptor file, and usually common (with the aforementioned caveats) when you install from marketplace.

27

when you side-load an app (i.e. install it from a https URL rather than from MPAC) you definitely don’t have a single shared secret. We use that a lot for development and monitoring (or even giving access prior to Marketplace approval, remember ;P). For us that is reason enough to support one shared secret per tenant.