Page tree
Skip to end of metadata
Go to start of metadata


Introduction

Linchpin Mobile offers two ways of connecting the mobile device app for iOS and Android with a Linchpin instance running on Atlassian Confluence Server or Data Center. On this page we introduce the technical foundation for authenticating the mobile app via direct connection. For more information on the authentication concept regarding the Linchpin Mobile Gateway, please see the documentation over here.


Setting up the authentication token

When the user connects the mobile device app with the app running in the Confluence instance for the first time, an authentication object for the mobile access is generated. The user has to submit his username and password to authenticate her- or himself. The app uses basic authentication via a https connection to do that. Every created authentication object created in that way is unique to the user and the device. Note: a user can use multiple devices, which each creates a new authentication object.

The generated authentication object that is saved in the Confluence app consists of the following information (it is saved in the active objects storage):

  • userKey → the Confluence User Key of the authenticated user
  • token → a 'type 4 (pseudo randomly generated) UUID' which is randomly generated for each access token
  • createDate → the current date/time
  • valid → is set to true at the beginning

After the authentication object is generated, the mobile app sends a device name to the backend to append to the authentication object. It uses the device manufacturer and the device model (both information are obtained through cordova).


Authentication after initial token exchange

The mobile app gets the generated token from the authentication object as a response and saves it on the device. Further communication uses this token in the following way:

  • The token is used as an additional header: `X-LINCHPIN-TOKEN`
  • The Confluence app uses a servlet filter, which does the following steps
    • looks up the user associated with the token
    • creates a Trusted Request using Confluence API calls with the user
    • the trusted request that uses the intentioned url is executed and the result is passed back to the mobile app. Using this trusted request mechanism ensures that the call respects the permissions associated with the user


Security

Due to the token using the associated user as a reference for the trusted requests, there are three options to secure access from malicious requests:

  1. Changing the user permissions will limit the content the user is able to see
  2. Deleting or disabling the user will deny access for any associated authentication objects
  3. Deleting the authentication object will deny the access from the specified device (only the admin can delete authentication objects)


  • No labels