Jira Oauth 2

[Rafael Nowning]

Thispage shows you how to configure OAuth 2.0 (3LO) (also known as "three-legged OAuth" or "authorizationcode grants") apps. OAuth 2.0 (3LO) allows external applications and services to accessAtlassian product APIs on a user's behalf. OAuth 2.0 (3LO) apps are created and managed in thedeveloper console.

For example, a Jira or Confluence site (resource), an Atlassian user (resource owner), and Gmail (client).Underlying the authorization interactions between these three parties is an authorization server.

If successful, the user will be redirected to the app's callback URL, with an authorization code providedas a query parameter called code. This code can be exchanged for an access token, as described in step 2.

Note, the permissions held by the user an app is acting for always constrain the app, regardlessof the app's scopes. For example, if a Jira app has the manage:jira-project scope but the userdoes not have the Administer Jira permission, the app can not create projects.

This will retrieve the sites that have scopes granted by the token (seeCheck site access for the app below for details). Find your site in the response andcopy the id. This is the cloudid for your site.

Therefore, since a grant can change over time, it's important that you check that the user has granted the app the scopes it requires and that your app has correct access to a site and its APIs. To check this, call the accessible-resources endpointon (you used this endpoint in a previous step to get the cloudidfor your site). The endpoint is described in detail below:

Each item in the response describes a container (for example, a Jira site) that your app has access to,the scopes associated with that access, and metadata such as the name and avatar URL (if any). It'simportant to understand that this endpoint won't tell you anything about the user's permissions, whichmay limit the resources that your app can access via the site's APIs.

You can securely manage all your OAuth 2.0 (3LO) and Forgeapps in one place using the Atlassian developer console.The console lets you view information about your apps, including their environments and scopes.

To add or remove individual scopes for an API, select Configure, and in the list of scopes,select Add or Remove. Note that users who previously consented to the scopes will needto re-consent to the new scopes.

OAuth 2.0 (3LO) currently supports the code grant flow only. It does not support the implicit grantflow. We understand that this is preventing people from using OAuth 2.0 (3LO) for standalone mobileapps and web/JavaScript (Chrome, Electron) apps and we are investigating ways to address this.

The current implementation of OAuth 2.0 (3LO) uses site-scoped grants, which means that the user onlygrants access to a single site each time they complete the consent flow. Be aware that there are a fewlimitations to this:

Jira apps can store and read the values of entity properties (issue properties and project properties)using the REST API. However, in the current implementation of OAuth 2.0 (3LO), Jira apps cannot declaresearchable entity properties.This means that if your app uses OAuth 2.0 (3LO), it won't be able to refer to entity properties in JQL queries.

Rotating refresh tokens issue a new, limited life refresh token each time they are used.This mechanism improves on single persistent refresh tokens by reducing the periodin which a refresh token can be compromised and used to obtain a valid access token.

To get a refresh token in your initial authorization flow, add offline_accessto the scope parameter of the authorization URL. Once you have the refresh token,exchange it for an access token by calling the token URL.

Only one grant exists per app for a given Atlassian account. If a user grants access to more than oneAtlassian site for this app, then the additional sites are added to the same grant. This means thatexisting access tokens will give you access to all sites and scopes that a user has granted your appaccess to.

The primary use for the state parameter is to associate a user with an authorization flow. This makesthe authorization flow more secure, as the authorization flow cannot be hijacked to associate a user'saccount with another user's token. Consider the following example scenario using Jira:

CORS whitelisting is supported for api.atlassian.com. CORS whitelisting allows OAuth 2.0 authorizationcode grants to work for browser-based XHR or fetch requests subject to cross-origin restrictions, suchas Chrome or Electron apps.

Each time they are used, rotating refresh tokens issue a new limited life refresh token thatis valid for 90 days. This mechanism improves on single persistent refresh tokens by reducing the periodin which a refresh token can be compromised and used to obtain a valid access token.

Every new refresh token returned invalidates the refresh token used to get the new access token. Your code shouldreplace the existing refresh token with the new refresh token. SeeUse a refresh token to get another access token and refresh token pair for more details.

OAuth is an authorization protocol that contains an authentication step. OAuth allows a user(resource owner) to grant a third-party application (consumer/client) access to theirinformation on another site (resource). This process is commonly known as the OAuth dance. Jirauses 3-legged OAuth (3LO), which means that the user is involved by authorizing access to their dataon the resource (as opposed to 2-legged OAuth, where the user is not involved).

In Jira, a client is authenticated as the user involved in the OAuth dance and is authorized to haveread and write access as that user. The data that can be retrieved and changed by the client iscontrolled by the user's permissions in Jira.

The authorization process works by getting the resource owner to grant access to their informationon the resource by authorizing a request token. This request token is used by the consumer to obtainan access token from the resource. Once the client has an access token, it can use the access tokento make authenticated requests to the resource until the token expires or is revoked.

In the Enter the URL of the application you want to link field, enter any URL, for example, , and then click Create new link. Ignore the No response was received fromthe URL you entered warning that is displayed and click Continue.

It doesn't matter what you enter in the remaining fields (URL, name, type, and so on). This isbecause we only want to retrieve data from Jira, therefore we only need to set up a one-way(incoming) link from the client to Jira.

We're now ready to authorize our client with Jira. This is the process of getting an access tokenfrom Jira (the resource), that our client (the consumer) can use to access information on the Jira site.

Note that to get the access token in OAuth, you need to pass the consumer key, request token,verification code, and private key. However, in the sample client, information like the consumer key, requesttoken, private key, and so on, are stored in the config.properties file when they are generated (have alook at it as you complete this tutorial and you'll see the new values added). You probably don't wantto do this for a production implementation, but this makes the sample client easier to use for this example.

An access token is all that we need to make an authenticated request to the Jira REST API using OAuth.Requests are made as the user who authorized the initial request token. The access token will persist for 5 years, unless it is revoked.

In the code, the sample OAuth client actually stores the access code in the config.properties file when itis obtained. When a request is made, the sample client passes the stored access code rather than you havingto enter it.

You can implement OAuth in a number of ways, depending on what you build. However, we encourage you tobrowse the source code for our sample Java OAuth client to get an idea of how it is implemented, regardless ofthe technologies that you use.

CAPTCHA is a tool that can distinguish a human being from an automated agent such as a web spideror robot. CAPTCHA is triggered after several consecutive failed login attempts, after which the useris required to interpret a distorted picture of a word and type that word into a text field with eachsubsequent login attempt. If CAPTCHA has been triggered, you cannot use Jira's REST API toauthenticate with the Jira site.

If CAPTCHA was triggered you will receive an error response from Jira when making requests throughthe REST API. You can determine if CAPTCHA is causing the error by checking if there is an X-Seraph-LoginReason header with a value of AUTHENTICATION_DENIED in the response. If present,this means the application rejected the login without even checking the password. While this is themost common indication that Jira's CATPCHA feature has been triggered, you can also check the numberof failed login attempts for the bot-user in Jira's user administration.

Has anyone undertaken getting the JIRA REST API connected via OAuth? I've been able to use the Jira connector via the credentialed method, which is fine for testing, but I'm looking for a little direction on getting both sides configured (JIRA admin and Alteryx). Any help would be appreciated.

@mnorris if you right click on the JIRA connector that is on the gallery you can open it up to see what it looks like on the inside. In the case of that connector, it uses Basic authentication which takes a username and password to create a concatenated string with a colon between the two, base64 encodes them, adds the word Basic in front of the new string, and passes that into a subsequent download tool as a Header. Basic Auth in Atlassian is outlined on their developer page here: -authentication/

Oauth in Alteryx looks slightly different. Normally in Oauth you would be passing some kind of client ID and client Secret to an authentication endpoint which would return a token that you would leverage in your next request to return back the data. Looking through the Oauth documentation here it looks like you first need to create an RSA public/private key pair, then create an application link, and finally call the application. Their primary example is in Java, but they also link to a bitbucket site where they have a Python example as well: -oauth-examples/src/master/python/

3a8082e126