Building a mobile SDK for on device issue reporting - how to authenticate?

Jira Development Jira Cloud
, , , ,
1

Hi everyone,

We’re building an open source mobile library that mobile developers and QA use during the development process to report user interface bugs directly from the device. The library takes a screenshot, allows users to enter a description of the issue, and then performs a HTTP call to create the new issue in the user’s JIRA project.

Currently, users generate an API key in their JIRA and pass that code into our library, which the library then uses to make the HTTP calls to their JIRA. This is a bit clunky, and means that their API key has to be hardcoded, so only 1 user/api key can be used at one time, as changing the user/api key would require the project to be rebuilt.

Is there a better way of doing this entire authentication flow?

EDIT: I was also looking at OAuth (which I think is still in developer preview), but as far as I can tell this requires a server. Can the OAuth flow be performed directly from a mobile app? If so, how?

2

Any further insight into this is appreciated. We’re currently stuck with our user’s having to either hardcode their API key before build time or entering the (very long) string of characters into a dialog.

3

Is there a better way of doing this entire authentication flow?

Hi CalebC, that’s exactly what the new feature 3LO aims to provide.

Below, I’ll describe 2 authentication flows you can follow.

I was also looking at OAuth (which I think is still in developer preview), but as far as I can tell this requires a server.

You are right.

Your app can authenticate without you having to provide a server. After authenticating, your app gets an authentication code.

But after authenticating, to call APIs of Jira (Confluence support will be available later), your app needs to exchange the authentication code for an access token.

To exchange, the authentication code and your app’s client secret need to be sent to Atlassian server. You don’t want to store the client secret inside your app, which hackers may analyze to extract the secret. That’s the reason you need a server, where you can store the client secret and do the exchange.

There are 2 authentication flows with 3LO you can follow:

Your app may open the 3LO login page inside its own in-app browser

Steps to login:

  • The user taps a button to login.
  • The app opens an in-app browser (WebView), showing the user the official login page.
  • The app monitors the URL at the in-app browser, to know when the user has been redirected to intended redirection URL containing the authentication code, e.g. Example Domain (this may be a non-existing address).
  • At that time, the app extracts out the authentication code, and closes the in-app browser.

For users, this way seems not secure, because an evil app developer (hope you are not one!) may freely inject custom JavaScript snippets into pages inside the in-app browser that he has full control, to steal username/password etc.

Your app may open the 3LO login page using system browser

Steps to login:

  • The user taps a button to login.
  • The app opens the system browser, showing the user the official login page.
  • After login, the system browser will redirect the user back to the app. For this to work, the app needs to registers a custom URL scheme (see doc of iOS and Android for details), and the redirect URL will look like myapp://redirect?code=xxx.

To prevent your custom URL scheme to be hijacked, please also use PKCE:

4 Likes
4

Hi @ndao, thank you for the detailed response. I’ve read both of your suggested authentication flows and each ends with acquiring an authentication code. Does this authentication code still need to be exchanged for an access token? In other words, do both of your suggestions still require our own server?