Details of 2-legged OAuth (2LO) with impersonation
This article only applies to Atlassian's server products. Learn more about the differences between cloud and server.
What does Atlassian pass as a credential when an application link is set up using OAuth with impersonation?
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.
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:
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
- 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
- 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