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, pleasesee 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 authentication object created in that way is unique to the user and the device.
A user can use multiple devices. Each device creates a new authentication object.
The generated authentication object that is saved in the Confluence app is saved in the active objects storage and consists of the following information:
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:
Changing the user permissions will limit the content the user is able to see.
Deleting or disabling the user will deny access for any associated authentication objects.
Deleting the authentication object will deny the access from the specified device (only the admin can delete authentication objects).
