Can Multiple users use oauth2.0 app

We are trying to integrate JIRA API to our application.
When we create a new case /update a new case using a JIRA api we need the JIRA ticket to be logged as created by the logged in user in our application.

1 Like

Welcome to the Atlassian developer community @RohitRavindra

Yes. Multiple users can use an OAuth 2.0 App. Each user will need to grant authorization. Your application can keep that grant as long as you hold a refresh token. Please note the expected change in behavior coming soon:

https://community.developer.atlassian.com/t/4-aug-2021-action-required-deprecating-persistent-refresh-tokens/50348

3 Likes

I’d also recommend giving this video a watch: Authentication on Atlassian Cloud - YouTube

@ibuchanan does a great job going over all of the authentication options and how they can/should be used.

3 Likes

Hi Team,

So the Use-case is we are integrating JIRA apis in our application and trying to achieve below scenario:

Suppose a user Rohit has registered an Oauth 2.0 application in Atlassian.

  1. Now this application has to be shared across multiple users (can you please let me the process on how this can be achieved).

  2. Now one of the users say Mark want to comment on an existing issue ,so we want that the comment to be registered on the name of Mark.Is this possible.if yes can you please let us know the process to achieve this.

@RohitRavindra,

As stated in the section on Distributing your OAuth 2.0 (3LO) apps:

When you create an OAuth 2.0 (3LO) app, it’s private by default. This means that only you can install and use it. If you want to distribute your app to other users, you must enable sharing.

The linked documentation explains how to share your OAuth app.

For each user, you will direct them to the Atlassian authorization URL once. Then your client will exchange the authorization code for an access token, which your client should remember per user. Then when Rohit or Mark want to create a comment, your client should use the associated access token. As explained originally, you will likely want to also use a refresh token so subsequent requests do not require returning to the authorization URL.

1 Like

Hi @ibuchanan ,
this is authorization url:

https://auth.atlassian.com/authorize?
audience=api.atlassian.com&
client_id=YOUR_CLIENT_ID&
scope=REQUESTED_SCOPE_ONE%20REQUESTED_SCOPE_TWO&
redirect_uri=https://YOUR_APP_CALLBACK_URL&
state=YOUR_USER_BOUND_VALUE&
response_type=code&
prompt=consent

In this above URL we are not specifying any user name, we just have state parameter which can be hash or any alphanumeric value. So on what basis atlassian will know that this request has come from Rohit or Mark?

@nilesh_pawar,

So on what basis atlassian will know that this request has come from Rohit or Mark?

The short answer is Atlassian doesn’t know. To be more precise, Atlassian will authorize that page as Rohit or Mark, but using Atlassian’s own identity provider; hence, the authorization URL doesn’t know Rohit or Mark in the same terms as the client.

Atlassian doesn’t need to know Rohit or Mark on the client terms (in fact, it shouldn’t because of privacy concerns). As I explained, that’s the job of your client. Your client knows Rohit or Mark when it starts the authorization URL and should use something like user session information to create the state parameter. That’s also explained in the documentation on What is the state parameter used for? After Rohit or Mark grant the authorization, Atlassian will call back to your client’s redirect URL, with the authorization code and the state. When your client receives the state, it is both a check to make sure the flow was not forged and a way to map back to your client’s notion of Rohit or Mark.

One thing you can do to visualize how this works (for development purposes only) is to use the user’s email address as the state parameter. That will let you see how the identity flows into and out of the authorization URL. In production usage, the state parameter must not be guessable outside of your client. The documentation linked above attempts to explain why.

Thanks @ibuchanan, for your helpful response. But I still need bit more explanation on this point,
Please find complete use case below

Suppose Rohit and Mark using their own client i.e DemoClientApp and they want to integrate jira in their DemoClientApp using Oauth2.0
So in order to do that Rohit created one Oauth2.0 app with his credentials in atlassian,
then from DemoClientApp Rohit sent authorization request with his state(his sessionid) parameter, got authorization code and then ultimately access_token.
afterwards Rohit added a comment on existing issue from DemoClientApp using his access token via rest api. And on the jira board that comment is appeared by the name of Rohit.

Now Mark logged in to DemoClientApp and want to add a comment on same issue. So he sent authorization request with his state(his sessionid) parameter, got authorization code and then ultimately access_token.
afterwards Mark added a comment on existing issue from DemoClientApp using his access token via rest api.
Now on jira board, will the comment added by the Mark appeared by his name?(our expectation)
In short, I am not able to visualize that, how jira will know that Mark has commented or Mark has created the issue because Oauth2.0 app is created by the Rohit and Mark is authenticated with state parameter(that could be his email or any alphanumeric value which is not going to be reflected on jira)
So jira/atlassian does not have Mark’s info, then how Mark can add comment on jira issue with his name?

Sorry for the trouble…!

@nilesh_pawar,

Something you asked made me wonder about the context of your DemoClientApp. You asserted:

So in order to do that Rohit created one Oauth2.0 app with his credentials in atlassian,

That should not be the case. You are creating an OAuth App in Atlassian, you are being granted a client id and secret, and your client is expected to be a single code-base, multi-tentant application. If your client is a packaged and distributed product, like Jira Server, then Atlassian’s OAuth (as implemented with authorization code grants only) is not the appropriate option. I would recommend API tokens collected for each user on your side.

Assuming you have a SaaS application that can keep a secret and can keep secrets for your users, then OAuth is the right option. Again, your product is the client, with a client id and secret managed in the developer console as an OAuth App. Rohit never shares his Atlassian credentials. That’s a critical advantage of OAuth. Let’s follow the sequence diagram:

The flow begins when 3rd party app (your product) wants to access something on the user’s behalf (Rohit). So your product constructs the authorization URL, including a state parameter that will later identify Rohit, and prompts Rohit for authorization. That prompt is a standard UI web page on Atlassian (not a back-end REST API). Rohit’s browser takes him to Atlassian where he must login (or proceeds if he already is) and is presented with scopes and the choice to grant access (authorize) your product. When Rohit approves, Atlassian sends a browser redirect back to your product, including an authorization code and the same state parameter that identifies Rohit. Atlassian will remember the connection between Rohit’s Atlassian identity and the authorization code, so that subsequent access tokens are issued with his user context. Mean while, the state parameter lets your client know this authorization code goes with your product’s user context for Rohit, and then subsequent access tokens your product requests should only be created when Rohit is the user.

In this first case, Rohit is “baked into” the user context of the authorization code and access tokens. When your product uses the REST API and an access token to create an comment, it’s as if Rohit were writing the comment. So Rohit appears in the Jira UI.

Now Mark comes along and also wants to make a comment. Your product already has an access token for Jira, but it was granted by Rohit. Your product should not use that to do things on Mark’s behalf. Neither Rohit, nor Mark approve that. So, your product needs to ask again, for a new authorization code and access token, this time on Mark’s behalf. So the authorization URL pops again, this time you are passing Mark’s state parameter and Atlassian makes Mark login. This time the returned code will be associated to Mark’s user context on the Atlassian side, and your product should use Mark’s state to keep his code separate from Rohit’s. If you use Mark’s code to get an access token, that token will work on Mark’s behalf, so when the comment REST API is called with that access token, then it looks like he wrote it.

To summarize, the authorization code grant never requires your product to ask for user credentials. Instead, the exchange lets Rohit and Mark both approve your product for a access token, which is tied to each user and with the minimum subset of access (the scopes) necessary for your product to do what each wants.

I would recommend just trying out the whole flow with a simple HTTP client. Here are the basic steps for something like curl or Postman:

  1. Create an OAuth App in the developer console. Make sure to select the scopes you intend to call in Jira. You can use a public URL like “https://example.com/” as the redirect URI (labeled “Callback URL” in the console). Don’t worry, nothing secret will leak in this example flow.
  2. Now construct an authorization URL. If you are in the Authorization screen of the Console, then you may see an example URL already. You only need to set a value for the state parameter. Since we’re just doing a developer walk-through, just use an email address. Paste the URL into a browser.
  3. In the browser, you will be prompted to authorize your own app. When you do, you will be redirected to the callback URL. Now you can see what your product would be getting back after authorization.
  4. On the back-end (curl or Postman), exchange the authorization code for an access token.
  5. Then use the access token to call the Jira REST API. You’ll see the access token acted “as you”, even though you never provided your credentials to the HTTP client.

Hope that helps.

2 Likes

Okay, @ibuchanan ,
Above informative comment helped a lot,
Now I got the whole story, thanks a lot, and salute for your patience.

Now, according to the documentation if multiple users want to use my app then I have to enable sharing or make it public.
So to make my app public I clicked on the given Marketplace URL - it asked me to signup to the ecosystem (as it was not accepting the existing credentials that I use for Jira and confluence)
I signed up and one form is been appeared. Could you please put light on the fields present in that form,
what input is expected by these fields? and where can I get it? especially Privacy Policy URL.

for example,
Summary (name of your app/integration)* - the name of which app? created OAuth2 app or our client(saas) app?
Tell us about the app you are developing - which app? created OAuth2 app or our client(saas) app?
Product: what should we use?
Privacy Policy URL: which URL and where I can get it from?

Apart from this, I have some other queries regarding the process

  1. How much time it will take to get approval once we create a ticket to distribute the app?
  2. After distribution, how many users can use that app? (any user limit?)

Thanks in advance…!

@nilesh_pawar,

If you are that close to sharing your app, then my first warning is that OAuth Apps are tied to 1 Atlassian account for now. If that’s your individual account, then there is no way to change that if you get a promotion or leave your current company. Therefore, I strongly recommend using a shared “service account”. There’s no special way to create that for Atlassian, but just use an email alias where group membership can be managed. Maybe “atlassian@example.com” or “integration@example.com”.

Next, recognize the distinction between sharing and making it public. Taken from Distributing your OAuth 2.0 Apps:

Enabling sharing doesn’t make your app available on the Atlassian Marketplace.

To put it differently, you don’t have to list on Marketplace. If you only want to share with other people (like in the same company), then you enable sharing without Marketplace.

Assuming you do want to go through with Marketplace, the next sentence is also important:

Although OAuth 2.0 (3LO) apps can be listed on the Atlassian Marketplace, they will appear as informational listings only, with limited Marketplace features.

With that context, answers to your questions…

Summary (name of your app/integration)

Overall, you should be describing the “integration” even if it is really a part of a larger SaaS product. See the guidance on Listing a third party integration on the Atlassian Marketplace

Privacy Policy URL

You don’t need one if you are “just sharing”. You do need one if you are publishing on Marketplace. See the Marketplace documentation about Data privacy guidelines. If your SaaS application is the client, then you can use the privacy policy of the whole product.

How much time it will take to get approval once we create a ticket to distribute the app?

In the documentation about how to Submit your app for approval, the documentation explains:

Each app is reviewed by a Marketplace support team member before being publicly listed. This process can take a while depending on the current number of submissions ahead of yours. Typically you should hear from a support member in 5 - 10 business days.

The best way to get fast service is to make sure you have followed the app approval guidelines.

After distribution, how many users can use that app? (any user limit?)

Atlassian will not limit by users. Your client may face rate limiting based on API usage. For OAuth 2, the metering is a combination of app + user, so the limits should be quite reasonable.

2 Likes

Thanks a lot, @ibuchanan for your promising coordination

1 Like

@ibuchanan
Thanks for such an descriptive answer. One question here that, in case when I want to share my app within my organisation, Under Distribution I can see the option for enable sharing but it is currently disabled and says it will be available soon. Then in that case how can I allow other users from my organisation to use the same authorization flow to get the access token.

@LovVerma,

If you can’t toggle “enable sharing”, then you can’t allow any other users. But I trust the messaging provided. In this case, it looks like you posted 4 hours ago. Assuming it was a global degradation of service, then “soon” was somewhere between then and now. Everything is working fine for me right now.

1 Like

@ibuchanan
Thanks for your quick response to my query. But I can’t see any time specified for that. Do we need additional admin rights for that or some other privilege?
Refer screenshot also.