Jira API authentication appears to be largely PAT-based now (both for cloud and on-prem instances).
The current state of New-JiraSession and Invoke-JiraMethod support PATs via -Headers or -Credential, but:
Understanding how to do this requires some level of HTTP knowledge (i.e. building an Authorization: Bearer <...> header),
Doesn't natively support [SecureString] tokens,
Doesn't work with Jira Datacenter (Basic auth is generally not recommended and will usually be mis-parsed as a local password)
Is generally pretty clunky.
Supporting bearer token auth natively would provide a more consistent experience.
Description
Improving PAT handling could look something like the following:
Add a PAT parameter (e.g. -PersonalAccessToken, with aliases -BearerToken and -Token) to New-JiraSession and Invoke-JiraMethod.
This is mutually exclusive with Basic auth (we'd be using Authorization: Bearer instead of Authorization: Basic), so we can enforce this with mutually exclusive parameter sets on the two functions.
In Invoke-JiraMethod, we:
Continue forwarding -Credential to Invoke-RestMethod if it's defined.
If a token is defined, we:
Pass it to Invoke-RestMethod via -Token on PS 6.0 and above (with -Authentication Bearer).
For PS5 and lower, we decrypt the SecureString ourselves and build the Authorization: Bearer header ourselves.
Use the username from the /myself endpoint when building session objects, instead of relying upon -Credential
PAT auth isn't guaranteed to come in as a credential, so relying on its username isn't guaranteed
Add some guard code to Invoke-JiraMethod and ConvertTo-JiraSession to ensure the username is always materialized
Additional Information
The one risk here is that Get-JiraSession now leaks the token we used to authenticate with in plain text. A couple of possible mitigations exist for this:
Add some code to ConvertTo-JiraSession to scrub auth headers
Extend JiraPS.Session to include a SecureString bearer token field and decrypt only as needed inside Invoke-JiraMethod
Context
Jira API authentication appears to be largely PAT-based now (both for cloud and on-prem instances).
The current state of
New-JiraSessionandInvoke-JiraMethodsupport PATs via-Headersor-Credential, but:Authorization: Bearer <...>header),[SecureString]tokens,Supporting bearer token auth natively would provide a more consistent experience.
Description
Improving PAT handling could look something like the following:
-PersonalAccessToken, with aliases-BearerTokenand-Token) toNew-JiraSessionandInvoke-JiraMethod.Authorization: Bearerinstead ofAuthorization: Basic), so we can enforce this with mutually exclusive parameter sets on the two functions.Invoke-JiraMethod, we:-CredentialtoInvoke-RestMethodif it's defined.Invoke-RestMethodvia-Tokenon PS 6.0 and above (with-Authentication Bearer).Authorization: Bearerheader ourselves./myselfendpoint when building session objects, instead of relying upon-CredentialInvoke-JiraMethodandConvertTo-JiraSessionto ensure the username is always materializedAdditional Information
The one risk here is that
Get-JiraSessionnow leaks the token we used to authenticate with in plain text. A couple of possible mitigations exist for this:ConvertTo-JiraSessionto scrub auth headersJiraPS.Sessionto include a SecureString bearer token field and decrypt only as needed insideInvoke-JiraMethod