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.

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: 

  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


Last modified on Nov 2, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.