How external integrations are supposed to figure users' Account IDs for impersonation?

Confluence Development Confluence Cloud
,
1

I’m building an external integration with Confluence. It’ll be integrated via Confluence REST API.

I’m following this guide: User impersonation for Connect apps

Once my addon is installed, my app receives “oauthClientID” and “secret”. If I understand correctly, I can use these to claim OAuth impersonation bearer token for any user to act on their behalf.

The user must be specified by their Account ID.
How am I supposed to figure what’s the right Account ID for each user?

I was thinking about performing user search first, and match users by their emails.
But the emails are hidden. The only info I get for a user is a display name (which is not reliable for users matching).

Any suggestions?

Thanks!

2

Depends on what you want to do. Usually you will use user impersonation in the context of a REST API call or a Web Hook or something like that. In that case the Account ID will be part of the request context.

If you want to impersonate certain users independently of an incoming request you will need to store their Account ID(s) beforehand, for example by letting an Admin pick users via a configuration page.

3

Thx Sven!

Is there any built-in mechanism to fire that Web Hook with user’s account ID?
E.g. redirecting a user from my site to Confluence Cloud where they’ll approve impersonation request and this fires the Web Hook?

4

I’m not sure we have the same understanding of webhooks here. Webhooks are requests to your app’s backend that are fired upon a certain event happening (such as a page being edited, created, deleted, etc.). They’re basically like event listeners.

From your description it sounds more like you would want to create a generalPage and display a button there that says something like “allow impersonation”. This button can then fire a REST request to your backend where you can either save the accountId for later use or directly execute the impersonation.

1 Like
5

Hi Sven,
I’m trying the approach with generalPage as you suggest. This looks promising, however I see one issue. The new “generalPage” is permanently sitting in the navigation menu (or is it call a toolbar?).
Is there any way not to show the page in the navigation menu?

6

Depending on what you’re doing - 3LO might be a better option: https://developer.atlassian.com/cloud/jira/platform/oauth-2-authorization-code-grants-3lo-for-apps/

1 Like
7

Hmmm are you sure you aren’t linking to it via a web-item? Can you post a screenshot of where the link is actually showing up?

I’m pretty sure I haved used a generalPage before and it wasn’t linked to unless I used a web-item. But you also might look into the 3LO thing that Daniel posted. :slight_smile:

8

3LO looks like the right fit indeed.

I have a few questions though:

Note, you cannot use OAuth 2.0 (3LO) with Atlassian Connect apps.

If I’m not building a connect app, that what is my application from the perspective of jira/confluence admin?
I mean, with Connect App, the admin would go to marketplace, install the app, and all the handshaking would just happen.
If I’m building just a 3rd-party app, how the organization admin allows 3LO requests for my app?
I’m pretty sure that security policy in most companies do not allow users to accept 3LO requests from random apps.

9

With a 3LO app - you’d point the user that you want to be able to assume the role of to an installation link. Once that user has installed your “app” - then you can do things on behalf of them. Its Cloud only…