Uploaded image for project: 'Atlassian OAuth 2.0'
  1. Atlassian OAuth 2.0
  2. OAUTH20-2493

Specify Allow/Block Lists for OAuth 2.0 (3LO) Apps

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • OAuth 2.0 Client
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Summary: Enable Admins to Specify Allow/Block Lists for OAuth 2.0 (3LO) Apps in Atlassian Cloud


      Description:
      Currently, administrators can only allow or block user-installed apps globally, as shown in the "Connected apps" settings (see attached screenshot). This approach lacks the granularity needed to manage specific OAuth 2.0 (3LO) apps individually. In many organizations, it is critical to have tighter control over what apps can access user data, particularly when OAuth 2.0 (3LO) apps require sensitive permissions and can be installed by any user without admin oversight.


      Request:
      In addition to the global allow/block option for user-installed apps, I propose introducing an allow/block list feature specifically for OAuth 2.0 (3LO) apps. This list would allow administrators to specify app access on a per-client ID basis, which is registered in the developer console, enabling admins to selectively allow or block each OAuth app.


      Given-When-Then Scenario:

      • Given administrators need to manage OAuth 2.0 (3LO) apps installed by users, which may have access to sensitive data or permissions,
      • When an administrator is configuring app settings in the "Connected apps" section,
      • Then they should be able to:
        • Specify a list of allowed OAuth 2.0 (3LO) apps using the app’s client ID.
        • Blocklist specific apps based on their client ID.
        • Maintain control over which OAuth apps are trusted within their organization, enhancing security and data governance.

      Concerns and Rationale for Improvement:

      1. Lack of Granular Control:
        Currently, admins can only globally allow or block all user-installed apps. This one-size-fits-all approach does not provide the flexibility needed in larger organizations with diverse security needs. Certain apps may be trusted and beneficial to users, while others could pose security or compliance risks.
      1. Need for Enhanced Security:
        OAuth 2.0 (3LO) apps often require extensive permissions that could expose sensitive data. Without control over which OAuth apps are allowed, organizations are left vulnerable to potential misuse of data. Selective allow/block control is crucial for mitigating these risks.
      1. Better Data Governance:
        Many organizations must adhere to data privacy and compliance standards, such as GDPR or HIPAA. Without fine-grained control over OAuth 2.0 apps, it becomes difficult for admins to enforce these standards, which can lead to compliance issues.
      1. Administrative Oversight:
        Currently, any user can install an OAuth 2.0 (3LO) app if global user-installed apps are allowed, leaving admins in the dark about which external applications are accessing data. An allow/block list would provide administrators with more oversight and control over the integrations accessing organizational data.

      Business Impact:
      Implementing this feature would empower organizations to maintain tighter security controls, improve compliance, and manage data access more effectively. By providing selective control over OAuth 2.0 (3LO) apps, Atlassian would support its enterprise customers in enforcing security policies and meeting regulatory standards, thereby increasing trust in the platform.


      Existing Limitations Compared to Forge and Connect Apps:

      To my knowledge, the following controls exist for Forge or Connect apps only and do not apply to OAuth 2.0 (3LO) apps:

      • Allow/Block List for Apps via Data Security Policies:
        Currently, admins can use data security policies to control access for Forge or Connect apps, but no such mechanism exists for OAuth 2.0 apps.
      • Ability to Install a Private App via Connected Apps Menu:
        Admins can install private apps in the Connected Apps menu, but this option is unavailable for OAuth 2.0 apps, which are often installed directly by users.
      • Ability to Install an Unlisted App via Connected Apps Menu:
        Similarly, admins can install unlisted apps in the Connected Apps menu for Forge or Connect, but this flexibility does not extend to OAuth 2.0 apps.

      These limitations highlight the need for improved controls around OAuth 2.0 apps to bring parity with Forge and Connect, enabling admins to manage app security consistently across app types.


      Attachments:

      • Screenshot showing current admin settings for user-installed apps.

              Unassigned Unassigned
              eb75a1d9670b Amandeep Singh
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: