Added log file entry in case Bearer Authentication with a token fails. Please be aware that these failures are currently not audit-logged. We'll add this soon in an upcoming release.

Added log file entry in case Bearer Authentication with a token fails. Please be aware that these failures are currently not audit-logged. We'll add this soon in an upcoming release.

Fixed a bug affecting the log file entries for tokens deleted on behalf of another user. The records mentioned the wrong user key. The audit log was not affected by that bug.

Fixed a bug affecting the log file entries for tokens deleted on behalf of another user. The records mentioned the wrong user key. The audit log was not affected by that bug.

Updated internal libraries to be compatible with the latest Jira releases

Updated internal libraries to be compatible with the latest Jira releases

New Feature

• accept authentication with API tokens on selected cluster nodes only, read more about it here

Improvement

• returning the id of a token in the create-token REST response
  • the id is required to delete tokens via REST API

New Feature

• accept authentication with API tokens on selected cluster nodes only, read more about it here

Improvement

• returning the id of a token in the create-token REST response
  • the id is required to delete tokens via REST API

New Features

• individual IP address restrictions for API tokens
  • in addition to IP address restrictions that the admin might have defined already, users can assign these on a per token basis
• (HTTP) header/ value access rules for API tokens
  • read more about it in our documentation

Changes

• UX/ UI improvements to accommodate new features

Bugfixes

• fixed a bug where users creating a token for themselves got an error that providing an OpenPGP public key is required
  • that only happened when admins enabled mandatory OpenPGP encryption for tokens created on behalf
• fixed a malformed response of the Jira session auth endpoint when it hit the token rate limit

New Features

• individual IP address restrictions for API tokens
  • in addition to IP address restrictions that the admin might have defined already, users can assign these on a per token basis
• (HTTP) header/ value access rules for API tokens
  • read more about it in our documentation

Changes

• UX/ UI improvements to accommodate new features

Bugfixes

• fixed a bug where users creating a token for themselves got an error that providing an OpenPGP public key is required
  • that only happened when admins enabled mandatory OpenPGP encryption for tokens created on behalf
• fixed a malformed response of the Jira session auth endpoint when it hit the token rate limit

• further hardening against username enumeration
  • in addition to the changes in version 2.0.2, the error message in a 401 response is now identical to the one Atlassian sends: "Basic Authentication Failure - Reason : AUTHENTICATED_FAILED"

• further hardening against username enumeration
  • in addition to the changes in version 2.0.2, the error message in a 401 response is now identical to the one Atlassian sends: "Basic Authentication Failure - Reason : AUTHENTICATED_FAILED"

• fixed a bug that caused UI not to load if the user logged in has no e-mail address set
• hardened app against username enumeration
  • removed mentions of usernames in responses that led to 401 - Unauthenticated
  • for troubleshooting purposes, admins can still look up details of authentication failures in the log files
• Updated internal and 3rd party libraries

• fixed a bug that caused UI not to load if the user logged in has no e-mail address set
• hardened app against username enumeration
  • removed mentions of usernames in responses that led to 401 - Unauthenticated
  • for troubleshooting purposes, admins can still look up details of authentication failures in the log files
• Updated internal and 3rd party libraries

• Updated internal and 3rd party libraries
• Improved text/ wording of a few element descriptions in the UI

• Updated internal and 3rd party libraries
• Improved text/ wording of a few element descriptions in the UI

New Features

• Audit logging of configuration changes
• OpenPGP Encryption for tokens created on behalf
• Tags/ Notes for IP address restrictions

Changes

• Users who can't create their own tokens but can use tokens can now see a list of their tokens, i.e. to see expiration dates or other details
• The list of tokens now shows an expiration warning if a token expires within the next 14 days
• Changed texts in the permission settings so that it's more clear what the on-behalf permission implies

New Features

• Audit logging of configuration changes
• OpenPGP Encryption for tokens created on behalf
• Tags/ Notes for IP address restrictions

Changes

• Users who can't create their own tokens but can use tokens can now see a list of their tokens, i.e. to see expiration dates or other details
• The list of tokens now shows an expiration warning if a token expires within the next 14 days
• Changed texts in the permission settings so that it's more clear what the on-behalf permission implies

Added support for Jira 8.22 and Jira 9

Added support for Jira 8.22 and Jira 9

Added logging of rate-limited requests. Read more about it here: https://wiki.resolution.de/doc/api-token-authentication/latest/admin-guide/logging#id-.Loggingv1.9.x-RateLimitedRequests

Added logging of rate-limited requests. Read more about it here: https://wiki.resolution.de/doc/api-token-authentication/latest/admin-guide/logging#id-.Loggingv1.9.x-RateLimitedRequests

• now supporting API Token authentication for non-REST /sr/ search request endpoint
• changed a few wordings in description texts of the audit logging page
• changed text for the audit/ log entry "user tried to authenticate with an invalid token or regular password" to "user is authenticating with an invalid token, or with a regular password"
• added a warning so that admins are aware of the fact that tokens that have been created before rate-limiting was enabled won't be rate-limited

• now supporting API Token authentication for non-REST /sr/ search request endpoint
• changed a few wordings in description texts of the audit logging page
• changed text for the audit/ log entry "user tried to authenticate with an invalid token or regular password" to "user is authenticating with an invalid token, or with a regular password"
• added a warning so that admins are aware of the fact that tokens that have been created before rate-limiting was enabled won't be rate-limited

Since version 1.9.x the app offers functionality to apply rate limits to requests authenticated with API Tokens. Read more about rate-limiting here: https://wiki.resolution.de/go/ata/rate-limit-admin

This bugfix adds a missing database field annotation so that updating the app on instances with MS SQL databases works flawlessly.

If you already updated to 1.9.0/1 and use MS SQL, please contact us at https://www.resolution.de/go/support.

Since version 1.9.x the app offers functionality to apply rate limits to requests authenticated with API Tokens. Read more about rate-limiting here: https://wiki.resolution.de/go/ata/rate-limit-admin

This bugfix adds a missing database field annotation so that updating the app on instances with MS SQL databases works flawlessly.

If you already updated to 1.9.0/1 and use MS SQL, please contact us at https://www.resolution.de/go/support

• extended audit logging so that failed authentication due to IP address restrictions is logged as well
  • until this version, this only happened when the app was configured to prevent Basic Authentication with regular passwords
• fixed a bug that caused a 401 response on certain REST endpoints when re-using an existing session that wasn't created with an API token

• extended audit logging so that failed authentication due to IP address restrictions is logged as well
  • until this version, this only happened when the app was configured to prevent Basic Authentication with regular passwords
• fixed a bug that caused a 401 response on certain REST endpoints when re-using an existing session that wasn't created with an API token

Now allowing authentication with API tokens on the /secure/attachment/ endpoint.

Before this version one had to use a session cookie to download attachments on this non-REST endpoint.

Now allowing authentication with API tokens on the /secure/attachment/ endpoint.

Before this version one had to use a session cookie to download attachments on this non-REST endpoint.

• Fixed a bug in IP address verification that caused client requests to be rejected even though they were in a range permitted
• Hardened and upgraded the internal license checker library to prevent issues when applying a new Atlassian application license

• Fixed a bug in IP address verification that caused client requests to be rejected even though they were in a range permitted
• Hardened and upgraded the internal license checker library to prevent issues when applying a new Atlassian application license

• Added a REST token test endpoint for support- and troubleshooting purposes, read more about it in our documentation
• Adjusted checks for requests to non-REST endpoints and if basic authentication with regular passwords is disabled
  • before this change, requests with a Basic Auth header would fail and result in HTTP error 403, even if a valid session was present already
  • this caused problems when working with certain libraries such as https://github.com/pycontribs/jira

• Added a REST token test endpoint for support- and troubleshooting purposes, read more about it in our documentation
• Adjusted checks for requests to non-REST endpoints and if basic authentication with regular passwords is disabled
  • before this change, requests with a Basic Auth header would fail and result in HTTP error 403, even if a valid session was present already
  • this caused problems when working with certain libraries such as https://github.com/pycontribs/jira

REST API only: when creating a token on behalf, the user key provided in the payload is validated first. If it doesn't belong to a user, HTTP status 400 and a message are returned.

To get familiar with the app, please refer to our documentation: https://wiki.resolution.de/doc/api-token-authentication/latest

REST API only: when creating a token on behalf, the user key provided in the payload is validated first. If it doesn't belong to a user, HTTP status 400 and a message are returned.

To get familiar with the app, please refer to our documentation: https://wiki.resolution.de/doc/api-token-authentication/latest

API tokens can now also be used as bearer tokens, read more about it in our documentation

API tokens can now also be used as bearer tokens, read more about it in our documentation

Security Improvement

• Immediately invalidate active sessions that have been created with API tokens and have expired or were deleted in the meantime (Previously the session remained active until the session timeout was reached)

New Feature

• Added option to disable Session Cookie Based Authentication

Full Release Notes

Security Improvement

• Immediately invalidate active sessions that have been created with API tokens and have expired or were deleted in the meantime (Previously the session remained active until the session timeout was reached)

New Feature

• Added option to disable Session Cookie Based Authentication

Full Release Notes

This version has been created to offer our API Token solution also for Bitbucket.

In addition, admins of Jira 8.14 (or greater) can now also disable/ enable the Atlassian Personal Access Token app from within the API Token app's system wide configuration page.

This version has been created to offer our API Token solution also for Bitbucket.

In addition, admins of Jira 8.14 (or greater) can now also disable/ enable the Atlassian Personal Access Token app from within the API Token app's system wide configuration page.

When using the session endpoint in Jira (/rest/auth/1/session) for authentication with an API Token and with no previous failed login attempts, a 500 error was thrown. This has been fixed now. That endpoint is used by other 3rd party apps, i.e. the Bob Swift CLI for Jira.

When using the session endpoint in Jira (/rest/auth/1/session) for authentication with an API Token and with no previous failed login attempts, a 500 error was thrown. This has been fixed now. That endpoint is used by other 3rd party apps, i.e. the Bob Swift CLI for Jira.

You can now use API Tokens not only on REST- but on any /plugins/servlet/ endpoints.This way, almost every app which is using Basic Authentication should be supported.

You can now use API Tokens not only on REST- but on any /plugins/servlet/ endpoints.This way, almost every app which is using Basic Authentication should be supported.

• You can now also use API tokens for authentication with Confluence Team Calendars. Please be aware of that you need to use tokens with Read & Write scope for that to work.
• We've also removed a misleading description on the permission page which suggested that there is a checkbox to grant everyone the "Create Token On Behalf Permission" permission.

• You can now also use API tokens for authentication with Confluence Team Calendars. Please be aware of that you need to use tokens with Read & Write scope for that to work.
• We've also removed a misleading description on the permission page which suggested that there is a checkbox to grant everyone the "Create Token On Behalf Permission" permission.

New Features:

• Token scoping: read/write and read-only scopes can be used to restrict which 3rd party connections and scripts can make changes to the Jira & Confluence database and which can only read data. Scopes are per token but Read-Write tokens can only be assigned by users with a specific permission or not restricted at all.
• Audit logging of authentication events for complete oversight of successful and unsuccessful 3rd party logins

REST only:

• Custom expiration dates for scripts and connections with a limited lifetime
• User key lookups by email in addition to the standard username argument

Improvements:

• New toggle box to prevent path traversal vulnerabilities in REST URLs, and other under-the-hood changes to make “Disable Basic Authentication with User Password” more secure

New Features:

• Token scoping: read/write and read-only scopes can be used to restrict which 3rd party connections and scripts can make changes to the Jira & Confluence database and which can only read data. Scopes are per token but Read-Write tokens can only be assigned by users with a specific permission or not restricted at all.
• Audit logging of authentication events for complete oversight of successful and unsuccessful 3rd party logins

REST only:

• Custom expiration dates for scripts and connections with a limited lifetime
• User key lookups by email in addition to the standard username argument

Improvements:

• New toggle box to prevent path traversal vulnerabilities in REST URLs, and other under-the-hood changes to make “Disable Basic Authentication with User Password” more secure

Fixed a bug where REST request headers containing a client IP address with a port number caused a null pointer exception. The exception was only thrown with one ore more IP restrictions applied.

Fixed a bug where REST request headers containing a client IP address with a port number caused a null pointer exception. The exception was only thrown with one ore more IP restrictions applied.

Fixed a security vulnerability, please read here for more details:https://wiki.resolution.de/doc/api-token-authentication/latest/security-advisories/2020-07-09-sql-injection-vulnerability

Fixed a security vulnerability, please read here for more details:https://wiki.resolution.de/doc/api-token-authentication/latest/security-advisories/2020-07-09-sql-injection-vulnerability

Fixed a security vulnerability, please read here for more details:https://wiki.resolution.de/doc/api-token-authentication/latest/security-advisories/2020-07-09-sql-injection-vulnerability

Fixed a security vulnerability, please read here for more details:https://wiki.resolution.de/doc/api-token-authentication/latest/security-advisories/2020-07-09-sql-injection-vulnerability

If configuration was not restricting token usage to sys-admins only, a low privileged user could overwrite token descriptions of other user's tokens via the REST API. To do that, a user would have needed to guess the id of a token to be used in the update call (tokens are added to the database with a sequential Id). This refers to overwriting token descriptions only. At no point was the actual token exposed or at Risk.

CVSS: Medium 4.3 CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

VRT:Broken Access Control (BAC) > Insecure Direct Object References (IDOR)

If configuration was not restricting token usage to sys-admins only, a low privileged user could overwrite token descriptions of other user's tokens via the REST API. To do that, a user would have needed to guess the id of a token to be used in the update call (tokens are added to the database with a sequential Id). This refers to overwriting token descriptions only. At no point was the actual token exposed or at Risk.

CVSS:Medium 4.3 CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

VRT:Broken Access Control (BAC) > Insecure Direct Object References (IDOR)

Fixed a bug where a user already authorized was not detected as such and caused a 403 error.

Added support for older/ outdated browsers (i.e. Firefox 59), which were preventing the frontend to load properly.

Fixed a bug where a user already authorized was not detected as such and caused a 403 error.

Added support for older/ outdated browsers (i.e. Firefox 59), which were preventing the frontend to load properly.

Added more token validity time options to choose from.So far, only 6, 12 and 24 month could be selected in the UI but now users can additionally select an expiration time ranging from 1 to 5 months.

Added more token validity time options to choose from.So far, only 6, 12 and 24 month could be selected in the UI but now users can additionally select an expiration time ranging from 1 to 5 months.

• added a checkbox so that admins can allow regular users to use API tokens created for them by admins or created earlier by regular user, prior limiting token creation to admin users
• added a wizard for easier setup and getting started
• added more in-app links to the documentation and our support center

• added a checkbox so that admins can allow regular users to use API tokens created for them by admins or created earlier by regular user, prior limiting token creation to admin users
• added a wizard for easier setup and getting started
• added more in-app links to the documentation and our support center

Bugfix:

• fixed the bug causing the failed login counter to be increased when using API tokens
• fixed the bug not returning the correct X-Seraph-LoginReason status value

New Features:

• tokens can now have a validity/ expiration time of up to two years
• sysadmins can disable token creation and usage for regular users
• sysadmins can create tokens for other users
• token creation and deletion will create audit log records in Jira and Confluence
• added a REST endpoint for sysadmins to filter tokens from all users in the system, i.e. to send expiration warnings with a custom automation

• fixed the bug causing the failed login counter to be increased when using API tokens
• fixed the bug not returning the correct X-Seraph-LoginReason status value

New Features:

• tokens can now have a validity/ expiration time of up to two years
• sysadmins can disable token creation and usage for regular users
• sysadmins can create tokens for other users
• token creation and deletion will create audit log records in Jira and Confluence
• added a REST endpoint for sysadmins to filter tokens from all users in the system, i.e. to send expiration warnings with a custom automation