Details of 2-legged OAuth (2LO) with impersonation
This Knowledge Base article was written specifically for the Atlassian Server platform. Due to the Functional differences in Atlassian Cloud, the contents of this article cannot be applied to Atlassian Cloud applications.
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