Confluence REST API token authentication

Adam_ksxny7

I'm looking to build an internal helper app using the Jira REST API.  Basically to automate/make easier some things that are a pain in Jira (WHy you can't have either fixVersions or Components globally I do not understand!)

 

The docs are quite against using cookie-based auth with the REST API.  However, my requirements are that:

• The user of my app has to log in/authenticate themselves.  They should do so using their Jira credentials
• The app then runs as that suer, so has pemrissions, etc. appropriate to that user and any actions are seen as being by that user.

 

I don't really see why cookie-based isn't actually the most secure here?  As I see it the options are

• OAUTH. I understand that you can impersonate a user when using OAUTH authenticaiton (https://community.atlassian.com/t5/Answers-Developer-Questions/How-do-you-impersonate-a-user-with-JIRA-oauth/qaq-p/476116).  But the problems I see are:
  • Impersonation isn't authentication
  • I guess I could authenticate by posting to auth/session, but then I'd have to implement session handling directly myself to keep track of which user it is for that session - all the drawbacks of cookie-based authentication and extra work
• Basic Authentication.  I guess this would be as the correct user, but it means I have to have a session (again, all the drawbacks) and also store the users password in that session, which should be a definite no-no

 

Is there something I'm missing, or are the docs just missing this use case when they recommend not using cookie-based?

 

Know about their current Jira session so they don't need to re-authenticate would be best of course, but if I want that I guess I need to bit the bullet and write a proper plugin, isntead of a quick, external, helper app

 

I'm probably going to go ahead and implement with cookies, just wondering what if anything I've msised here.

E.L. Fridge

Hi Adam, it seems like your question was based on Jira even though you mention confluence in the subject, so I'm answering it from a Jira point of view.  I also see this is an older question but it was listed on the list of pending questions with out a response in the community, so here goes:

Another option that you may not have considered is using a service account in Jira to do the actions on the persons behalf.  So, you'd create a local service account in Jira and give it only the access it needs to perform the actions it should do.  We have a persona called "Jira Bot" that comments on issues, transitions them, etc.  If you make a new issue on someone's behalf you can still put that person as the reporter even though Jira Bot did the actual work. 

We like this method because each person doesn't have to share their credentials and it's really clear what work is being done by the bot and what is being done be the actual user.