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

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: 

   plugins/servlet/oauth/authorize
   Method:POST
   
   oauth_token:9XfaPGFDI0s658H8hnu6cxslP0ApHCam
   oauth_callback:https://support.atlassian.com/ja/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