Hi community!
Our team is working on integrating ServiceNow with Jira via API and we have seen that what we need is a OAuth 2.0 integration app so Jira Spoke (and addon installed and configured in ServiceNow) can perform operations in the instance.
The question that we have is: can the app integration stop working if the user that created it is removed from the instance?
Thanks in advance.
Regards,
Raul Lopes, Atlassian Product Developer.
Welcome to the Atlassian developer community @RaulLopes,
Yes. Although I have not tested it myself, the access tokens provided by Atlassian are revocable and should be revoked if the user who approved no longer has product access. The propagation would be automatic and would not require any user intervention. As a consequence, the integration in question (Jira Spoke) would begin to receive 401 statuses on requests and would need to re-authorize.
Hi @ibuchanan,
Thank you for your answer. Then the solution is to use a generic user right?
On another note, Atlassian suggests us to use Jira Spoke to integrate both applications, but our original idea is to execute all operations via code from ServiceNow to Jira using the API.
The user (in ServiceNow) would authenticate via OAuth 2.0 to execute all the operations (create issues, upload attachments, etc.). We have followed this documentation trying to get the token but we haven’t managed to do so.
In our case, the user would not be directed to a window to give permissions to the app because all of the steps need to be executed via API, so my question is: is it possible for a user in ServiceNow to access the Jira API via OAuth 2.0 Authentication?
Thanks again.
Regards,
Raul.
For OAuth 2, that’s your only option because Atlassian only supports the authorization code flow.
I don’t follow the question. The “3LO” flow (known more formally as the authorization code flow) fundamentally requires a Jira user to authorize the app through the authorization page. While there are some ways to separate the app from directly initiating the flow or receiving the authorization code, those require a sophisticated user to know how and where to paste URLs & parameters between the web and the CLI.
All that said, what you want to do is done better with a system-to-system authorization model. In OAuth 2, that might be client credentials flow, but that’s not supported in Atlassian’s OAuth. But “as app” auth is supported in our app frameworks like Connect and Forge (and specifically about “as app” auth). I don’t know anything about the ServiceNow world, let alone Jira Spoke specifically, so maybe that is not an option. Even if you do have control over the end-to-end architecture, there isn’t really any documentation or example I can point you towards.
Since I don’t know how Jira Spoke works, can you say more about how it fits with OAuth tokens? Does Jira Spoke already know how to “speak OAuth”?
Could you give some examples? The user in ServiceNow is be a developer who needs to integrate to auth2.0 to perform some actions with the Jira API, so we can probably make it work.
Jira Spoke needs that we:
Set the callback URL with the ServiceNow instance URL
Provide the cloud id of our Atlassian jira Software instance
Create an application registry record in ServiceNow: here is where we introduce specific data about our Atlassian app e.g client:id, client_scret, etc.
Create a credential record for the Jira Spoke i.e the credential that Jira Spoke uses to authorize actions
Hope that information helps.
Now that you’ve linked to the docs, I had a quick look. Jira Spoke does apparently “speak OAuth”. I don’t think you should need to be messing around with OAuth 2 on the CLI. It certainly should not be needed by Jira Spoke. That said, maybe you’ll find some diagnostic value making sure that your app settings are valid, so I’ll share some tools here.
curl.ATLASSIAN_APP_3LO_CLIENT_ID and ATLASSIAN_APP_3LO_CLIENT_SECRET.atlassian-oauth2.sh. Make sure it has execute permissions.#!/usr/bin/env sh
SCOPES='offline_access read:me'
REFRESH_TOKEN=`jq --raw-output '.refresh_token' access_token_response.json`
if [[ -z "$REFRESH_TOKEN" ]]; then
echo "Performing authorization code flow to obtain initial access token response"
oauth2c https://auth.atlassian.com/ \
--client-id "$ATLASSIAN_APP_3LO_CLIENT_ID" \
--client-secret "$ATLASSIAN_APP_3LO_CLIENT_SECRET" \
--response-types code \
--response-mode query \
--grant-type authorization_code \
--auth-method client_secret_post \
--scopes "$SCOPES" \
--silent \
> access_token_response.json
else
echo "Performing refresh token flow to obtain a fresh access token response"
oauth2c https://auth.atlassian.com/ \
--client-id "$ATLASSIAN_APP_3LO_CLIENT_ID" \
--client-secret "$ATLASSIAN_APP_3LO_CLIENT_SECRET" \
--grant-type refresh_token \
--auth-method client_secret_post \
--refresh-token $REFRESH_TOKEN \
--silent \
> access_token_response.json
fi
ACCESS_TOKEN=`jq --raw-output '.access_token' access_token_response.json`
xh https://api.atlassian.com/me \
--verbose \
--auth-type bearer \
--auth "$ACCESS_TOKEN"
The above should spit out some JSON about you (or whoever has granted access in the flow). The oauth2c command also has an interactive mode so you can also just type oauth2c and refer to some of the values above to see a little more information.
Hi @ibuchanan,
Sorry for not getting back to you earlier. I think I didn’t explain myself properly, we do not need to check if the app settings are valid, what we need is to get the authorization token (step 1 of the 3LO documentation) without redirecting the user to a page i.e only programatically.
If I understood it right, currently this requirement is not feasible.
Anyway, thenk you for your help.
Regards,
Raul.
I confirm that is not possible with the authorization code flow. Since the Atlassian flow only supports authorization code grants, then it cannot be done without an explicit user consent. A different flow, like the client credentials flow (as yet unsupported), would be required to do this entirely programmatically.