Details of 2-legged OAuth (2LO) with impersonation

Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Question:

What does Atlassian pass as a credential when an application link is set up using OAuth with impersonation?

Answer:

Short answer: App doesn't pass anything as a credential during creation of the link, it relies on proper cookie from another App to login. Later it uses oauth_token.

Detailed answer

Main logic of authentication and authorization flow is based on the standard 2-Legged OAuth but with a small variation inspired by how Google implemented the protocol oauth_prot

In our case we use following 2-Legged OAuth flow:

  1. Admin setup 2-Legged OAuth with impersonation between applications AppA and AppB.

  2. User initiates Trust action

  3. AppA redirects user to AppB page, call: plugins/servlet/applinks/oauth/login-dance/authorize?applicationLinkID=LINK_ID

  4. AppB checks if user is authenticated (authenticate the user if required)

  5. AppB generates auth_token, call: plugins/servlet/oauth/authorize?oauth_callback=AppA_page&oauth_token=9XfaPGFDI0s658H8hnu6cxslP0ApHCam

  6. AppB asks for approval and stores the reply, call: plugins/servlet/oauth/authorize, Body:

    1 2 3 4 5 6 plugins/servlet/oauth/authorize Method:POST oauth_token:9XfaPGFDI0s658H8hnu6cxslP0ApHCam oauth_callback:https://support.atlassian.com/plugins/servlet/applinks/oauth/login-dance/access?applicationLinkID=LINK_ID approve:Allow
  7. AppB redirects back to AppA with oauth_token, call: /plugins/servlet/applinks/oauth/login-dance/access?applicationLinkID=LINK_ID&oauth_token=9XfaPGFDI0s658H8hnu6cxslP0ApHCam&oauth_verifier=verify_ID

  8. AppA stores the new oauth_token for the user.

  9. user at AppB trusts to AppA to execute action at AppB on it's behalf based on oauth_token.

You can see additional details here: OAuth+security+for+application+links

Updated on April 17, 2025

Still need help?

The Atlassian Community is here for you.