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:
Admin setup 2-Legged OAuth with impersonation between applications AppA and AppB.
User initiates Trust action
AppA redirects user to AppB page, call: plugins/servlet/applinks/oauth/login-dance/authorize?applicationLinkID=LINK_ID
AppB checks if user is authenticated (authenticate the user if required)
AppB generates auth_token, call: plugins/servlet/oauth/authorize?oauth_callback=AppA_page&oauth_token=9XfaPGFDI0s658H8hnu6cxslP0ApHCam
AppB asks for approval and stores the reply, call: plugins/servlet/oauth/authorize, Body:
1 2 3 4 5 6plugins/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:AllowAppB 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
AppA stores the new oauth_token for the user.
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
Was this helpful?