New 3LO app controls

[JuliaDaehne]

Hello, everyone!

An improvement will be made in the coming days to allow customers (site admins) to turn off (or back on) end-user installation capabilities for OAuth 2.0 (3LO) apps. If you are a developer of OAuth 2.0 (3LO) apps, you do not need to take any action as a result of this change, as this message is only to communicate the impact to the customer.

Previously, controls were not in place for an admin to block their users from installing 3LO apps. Adding the ability for an admin to prohibit users from installing 3LO apps now aligns more closely to how a user would install any other, non-3LO apps on the Marketplace. This functionality was requested by several Atlassian enterprise customers to gain increased control over where their data is shared and which apps have access to their instance. By allowing admins to control end-user app installs, we are making it possible for more enterprise customers to move to cloud. Once in cloud, these companies will not be blocked from installing 3LO apps, because admins will retain the ability to vet and install the apps at their discretion.

Figure (a) below demonstrates the section of the customer’s admin console where they will now be able to block their users from installing 3LO apps. Figure (b) below shows the new experience when a customer tries to install a 3LO app after their admin has disabled this function.

If a customer attempts to install a 3LO app after their admin has disabled this function, the following error message will appear:

App is blocked by an admin
An admin has not allowed [App Name] to access data from [Your Atlassian Instance] . Select another site to authorize access to or contact your admin for more information.

(a)

(b)

Thank you, and please let us know if you have any feedback or questions,

Julia

[andreas.schmidt]

If you are a developer of OAuth 2.0 (3LO) apps, you do not need to take any action as a result of this change, as this message is only to communicate the impact to the customer.

Except for… Users often don’t know their admins. They will contact us if the app does not work.
So we need to update our support team.

Additionally it would have been great you would not reinvent the wheel every time.
With Connect apps you already have a “request app” workflow where users could request a specific app. Why not reuse that for OAuth2 apps as well so the user can directly contact the admin?

[Edit] Also, what happens to existing consents when the admin revokes the app?

[JuliaDaehne]

Hi @andreas.schmidt yes that’s a good point about the support requirement. This is a slow release, ie only 5% of customers will see the new feature to start with and we ramp up to 100% over following 5 days. Does this give you enough time to update the support team about the new feature?

As for the existing consent: when the app is uninstalled the existing app grants are removed from the app. The user cannot re-connect to the app once the Admin has toggled the block