Thank you @ibuchanan for the detailed explanation.
I know that the validity of the refresh_token is extended each time a user uses it to request a new access_token. I have this option (Use rotating refresh tokens) already enabled in my staging environment. This adds one more layer of complexity on top of my existing OAuth implementation ;).
I am not expecting my ‘power-users’ to actually face one-month breaks. But the content they create can be accessed by random people in the organisation. These users are very likely to face the “You need to authorise the plugin” problem.
More importantly, the need to authorise the plugin is annoying despite currently lifetime refresh tokens. From a user perspective, Jira and Confluence are part of the same ecosystem. Why should they authorise if the link between these two is already set up?
To wrap up: I am still interested in using a bridge/link and bypass OAuth.
Following up on what @danielwester wrote:
Does this mean that the ‘Jira app’ will connect to the ‘Jira instance’ as ‘app’ (or service-account to use cloud naming)? So actually these two apps will create a bridge between two instances?
(possibly it’s a silly question, but I am deep in OAuth way of thinking so the above is not clear for me)