Fails to account for SSO logins

[masukomi]

Describe the bug
when using jira init it requests an email and immediately errors with 401 Unauthorized. This is, presumably, because at our company we use Single Sign On to authenticate, not our emails.

Short term suggestions:

• document that SSO isn't supported in the Readme (so that folks don't bother installing it if they can't use it)
• ask what form of authentication the person uses before requesting the email and indicate that SSO isn't supported if they choose it, or if it's possible to determine that SSO is what's configured when you query the server, just indicate that that's the problem in the error message.

Please provide following details

1. JiraCLI Version:

(Version="1.1.0", GitCommit="3b93e147eac468ad985bdece27469153b4bb2814", CommitDate="2022-08-14T08:10:40+00:00", GoVersion="go1.18.3", Compiler="gc", Platform="darwin/amd64")

2. Are you using Jira cloud or on-premise jira server? Also mention the version for on-premise installation.

   Jira cloud
   

3. What operating system are you using? Also mention version.

   macOS Monterey 12.6
   

4. What terminal are you using? Also mention version.

   iterm2 build 3.5.0beta7
   

To Reproduce

Steps to reproduce the behavior:

1. have a jira cloud account that uses SSO
2. run jira init and give it a valid email address
3. See error

Expected behavior
I'd expect it to either work, or to provide me with an indication than SSO isn't supported.

[ankitpokhrel]

Hi @masukomi, I am also using jira-cli with SSO in my company but its a self-hosted Jira Server. I think it should work if are able to generate Personal Access Token (PAT).

Basically what I am doing is:

• Set JIRA_AUTH_TYPE to bearer
• Generate PAT (Click on your pic in Jira -> Profile -> Personal Access Tokens)
• Set JIRA_API_TOKEN to the generated personal access token
• Run jira init and use your email or username.

[illfygli]

I started using it today and had the same problem.
Turned out to be an old version I had lying around in .local/bin. :)
I tried to use it before we could create PATs, which didn't work, but now it does so I tried again.

So as another data point I can report that it works great with my employer's Jira installation, which uses SSO (AD-based I believe).

@masukomi Have you tried using the username that appears on your Jira profile page, instead of an email address, if they differ? That username + PAT works for me.

You can also try jira init --debug and see if there's anything interesting, if you haven't already.
Verify that it says Authorization: Bearer jFLKsajflksDetc in the request.
You can also check for failed logins on your Jira profile, then you know if jira-cli has made it that far.

@ankitpokhrel Thanks for this tool, it's a nice accessibility aid for me. :)

[iouri-forusall]

same issue for me:

Set JIRA_AUTH_TYPE to bearer
Generate PAT (Click on your pic in Jira -> Profile -> Personal Access Tokens)
Set JIRA_API_TOKEN to the generated personal access token
Run jira init and use your email or username.

Results in:
Received unexpected response '401 Unauthorized' from jira. Please try again.

Weird thing is that I can see token being used by going to jira, it shows that it has been used within a minute which leads me to think that maybe it's "permissions to use API on jira/Atlasian" side of things? Is there such a thing?

[Akorian]

I'm also having this problem.
What I can tell from jira init --debug , I'm still using the basic auth even tough, I have enabled the bearer method via my .zshrc. I restarted my shell and checked if I can echo the content of the env vars - I could.

My company uses a SSO service, that I don't know. Also, we are selfhosting. -> I selected Local whilie init. And for the username, I selected the username shown on my Profile Page as well as my email (tried both).

My .zshrc
Is the position inside the file relevant?

JIRA_AUTH_TYPE=bearer
JIRA_API_TOKEN=<imagine my token here>

I use Fedora Linux on a Thinkpad T590. I instlled via homebrew.

[illfygli]

My .zshrc Is the position inside the file relevant?

JIRA_AUTH_TYPE=bearer
JIRA_API_TOKEN=<imagine my token here>

@Akorian You need to export them too, export JIRA_AUTH_TYPE=bearer, to make them available to other programs.

[spprashant]

FWIW, I have a work JIRA instance with SSO (via Google Auth). These steps worked for me.

• Generate API token using https://id.atlassian.com/manage-profile/security/api-tokens
• Add export JIRA_API_TOKEN=<GENERATED_TOKEN> in your .bashrc file.
• Do NOT add a JIRA_AUTH_TYPE setting, it did not work for me when this was set to bearer

[sseneca]

I also can't get this to work with SSO (Azure) with any combination I've tried:

• I've tried exporting the env vars
• I've tried using an API token
• I've tried using a password
• I've tried using the keychain password manager as described here
• I've tried using the .netrc file

On macOS, installed via Homebrew. I see the following error:

✗ Received unexpected response '401 401' from jira. Please try again.

[comjf]

I ran into this today as well. @spprashant documented the workaround that unblocks me (don't set JIRA_AUTH_TYPE)

[ankitpokhrel]

@comjf / @spprashant are you using local Jira installation? The token generated in local installation is used with basic auth IIRC so we don't need to set JIRA_AUTH_TYPE to bearer.

[igbanam]

Could we potentially get something like this setup for SSO servers on intranets

https://github.com/go-jira/jira/blob/4263bd24f9e9c702a92358c5cd7ce0ddd711df4c/jiracli/cli.go#LL240C5-L240C5

[XVilka]

Would be nice if instead of that error it will show the suggestion to set these two environment variables.

[dod38fr]

In my case (Oauth2 SSO with PingId), setting up a bearer token is not enough:

⠹ Verifying login details...

REQUEST DETAILS
------------------------------------------------------------

GET /rest/api/2/myself HTTP/1.1
Host: confluence.[redacted]
Authorization: Bearer [redacted]


✗ Received unexpected response '404 ' from jira. Please try again.

I've verified with my browser that the API endpoint does exists. A similar call is done with my browser. But my browser sends a huge cookie with the request instead of a token.

I guess that jira-cli needs to perform the Oauth dance to be able to log in with PingId.

Hope this helps

[spprashant]

@comjf / @spprashant are you using local Jira installation? The token generated in local installation is used with basic auth IIRC so we don't need to set JIRA_AUTH_TYPE to bearer.

@ankitpokhrel I confirmed with my IT admins, we are using the cloud JIRA instance. So unsure why the bearer setting doesn't work.

[matt-carr]

I get the same issue with Okta SSO, but only if I'm not on my company VPN.

[colindean]

I've got an SSO in front of my self-hosted JIRA instance. I was able to create a PAT at https://jira.EXAMPLE.COM/secure/ViewProfile.jspa?selectedTab=com.atlassian.pats.pats-plugin:jira-user-personal-access-tokens and place it in my .bashrc:

export JIRA_API_TOKEN=<the token>
export JIRA_AUTH_TYPE=bearer

and jira init ran just fine after asking my login info.

[peterrus]

I am using Jira Cloud with Atlassian's SSO and I just need to set this:

export JIRA_API_TOKEN=<the token>

Setting username and password in .netrc (without manually setting the token) leads to a '401 Unauthorized' because jira init --debug tries to authenticate using Basic Auth, which I guess is not supported once you move to Atlassian's SSO. When explicitly passing forcing Bearer Token auth with JIRA_AUTH_TYPE=bearer jira init --debug I see that the value of the bearer token is not sent along.

It'd be nice if we could set the JIRA_AUTH_TOKEN in the .config/.jira/.config.yml so I don't have to have such a sensitive token in my env vars at all time. For now I have just created the following alias in my .bashrc/zsh config:

jira() {
  # launch in a (subshell) so the api token doesn't linger in env after running
  (source ~/.config/.jira/api_token.env && command jira $@)
}

the api_token.env file contains:

export JIRA_API_TOKEN=th3t0k3n

[MilanJa]

If I curl a jira instance that is behind Amazon Cognito with my PAT in the authorization header and follow the location header like so
curl -L -H "Authorization: Bearer [token]" https://jira.[domain].com/rest/api/2/myself
I get 302 redirected to the Cognito login page so jira init fails for me.