Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Issues with OAuth Site Selection and Access Token Assignment in Atlassian Integrations

google agentspace
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 24, 2025

We are currently testing Confluence integration with our app and below are the issues we see. and this holds true for Jira or any Atlassian app.

Scenario:

  • A user successfully creates a Confluence integration on site1.atlassian.net.
  • Later, site1 is deactivated or deleted, but the OAuth authorizations associated with it are not revoked.
  • The user then attempts to create a new Confluence connector on site2.atlassian.net, which has Jira but not Confluence.
    • Problem 1: The OAuth consent screen still lists site2 as an option, even though only Confluence scopes are requested and site2 is not a Confluence site.
    • Problem 2: After site selection, the token exchange succeeds but returns a token that cannot be usable on site2.atlassian.net as it doesn't have Confluence.
    • Problem 3: Our app then shows a tenant/site picker by calling GET /oauth/token/accessible-resources, which only lists site1 (since that's the only site which our app earlier got authorized to and now it's deactivated), even though the user intended to create a connector for site2.
    • Problem 4: The user, expecting to reconfirm their previous choice, proceeds without noticing that they are reconnecting to an unintended or deactivated site(site1).
    • Eventually, our app tries to make an API call for a deactivated site (site1), and a 401 error results. Alternatively, if the site site1 was still active, the integration would have got created for the wrong or unintended tenant(site1).

This scenario highlights major flaws in user choice handling and site filtering in the current OAuth implementation.

 

Requested Improvements

  1. Return Selected Site in Token Exchange Response

    • Please enhance the token exchange to return the selected site ID like below, similar to Notion’s API. This would allow applications to reliably associate tokens with the user’s intended tenant and eliminate redundant site selectors/screens.

       

      HTTP/1.1 200 OK

      Content-Type: application/json


      {

        "access_token": <string>,

        "expires_in": <expiry time of access_token in second>,

        "scope": <string>

        "siteId": <string>

      }

  2. Filter Site List in Consent Dialog

    • Only display relevant and active sites in the consent dialog, based on the scopes requested (e.g., only Confluence enabled sites when requesting Confluence scopes).
    • Prevent selection of deactivated sites or sites where the requested application is not available.
  3. Do Not Issue Access Tokens for Deactivated Sites

    • Block the issuance of access tokens for sites that have been deactivated or deleted to avoid authorization errors and confusion.

0 answers

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
ENTERPRISE
TAGS
AUG Leaders

Atlassian Community Events