We have an existing integration (oauth 3lo) that allows users to create jira issues. We have been dealing with a lot of problems with users needing to reauthenticate with jira. While part of this was due the the troubles relating to the granular scopes rollout, the issues persist and we are wondering if there are alternatives.
We’d love to be able to grant access as an app, not as a user then pass along appropriate user ids if the situation warrants. We do want to read user info so we can assign users etc.
We use rotating refresh tokens and and properly update our tokens but users need to reauthorize fairly consistently and this is a terrible user experience since the need can arise after some background issue create/update task is happening… which will fail due to re-auth need.
Are there other development strategies that could mitigate this (eg Connect)? Are there alternatives for 3LO OAuth apps?
We’d love to help our (and Atlassian’s) users but the platform is making it quite difficult and I’d love to hear if there’s another approach we can use.
Welcome to the Atlassian developer community @lincoln,
Can you provide a bit more context about your app? Is it something listed on Marketplace? While solving for your user impersonation needs, I would hope we can avoid introducing other problem that come from the limits of the alternatives.
In the interest of making the best use of what you already have, can you explain a bit more about the conditions that cause your app to ask for reauthorization? I certainly sounds like a bad user experience but I’m wondering about the underlying technical implementation.
I slightly better understand the functional context but I still don’t understand the technical. Can you explain a bit more about the conditions that cause your app to ask for reauthorization?
Sure, but my question is more whether it’s possible to have our app not act as a specific user. You see, our app helps automate workflows that include jira. These workflows may not include one specific user, say the user who initially installed the jira app. This might be fine except that for a variety of reasons the need to reauthorize can arise: the user changes their jira password, the installing user has left the organization, bugs similar to what happened earlier this year with scopes. All of these things cause our app problems trying to do its job. This is especially bad since not all work is done in the foreground and reauthorization, even if the user is available, may not be an option.
I’d also not that tokens changing when passwords change is particularly bad since mandated password changes are pretty common and it means that 3lo apps will constantly be broken.
I’d love to hear that there are some alternatives or workarounds.
No, not with 3LO, better known more broadly as OAuth 2.0 authorization code flow. This flow is meant for clients to act on behalf of a user. While there is a related client credentials flow (aka 2LO), the scope of available APIs (known as Open DevOps APIs) would preclude your scenario.
That’s not a specified behavior of our 3LO implementation. Is this something you observed during testing? If so, I would certainly characterize it as a bug.
And, to return to your query from your original post:
Currently, you would find this described as asApp in Forge or Connect. In Forge, your code explicitly specifies asApp. In Connect, your code applies JWT authentication that is effectively asApp by default.
For your integration scenario (you already have a platform), Forge or Connect would act something like an API proxy. This means for either approach, your product must still have a way to auth to the Forge or Connect App. For Forge, that would mean your own auth code behind a web trigger, running in Atlassian infrastructure. Or for Connect, it’s more “anything goes” as a Connect App is basically “you build it, you run it”. That means you could host the Connect App parts within your product so auth is by means of “same process” (inside your infrastructure). Overall, there are few examples of integration via Forge and it is not yet recommended for that scenario. Many SaaS companies like yours have been successful in “system to system” auth using Connect.
That’s not a specified behavior of our 3LO implementation. Is this something you observed during testing? If so, I would certainly characterize it as a bug.
I’m basing the password change behavior on the docs here for 3lo apps:
We have been trying to provide guidance to our customers when things don’t go as expected and, while this is a confluence doc link, it’s a little unclear if it generally applies since it talks about the Atlassian account password in general. Perhaps we misunderstood.
Many SaaS companies like yours have been successful in “system to system” auth using Connect.
This sounds promising. Are there resources that might help us to determine if migrating to Connect is appropriate?