This page describes the specific OAuth errors that can be diagnosed automatically by application links and the actions you can take to correct those errors.

Application links, from version 5.2, only use OAuth authentication because of the greater security inherent in that protocol. Atlasssian doesn't recommend or support the Trusted Applications or Basic Access authentication types anymore. See OAuth security for application links for more information.

On this page:

 

 

Unrecognized OAuth consumer key

The application link was attempting to authenticate with the remote application but the OAuth credentials were rejected, either because the consumer key is stale, or it has no matching link.

You may see this error message in the Atlassian application logs:

oauth_problem=consumer_key_unknown
Possible causes
Actions you can take
  • The consumer key is stale.
  • There is no matching application link configured on the remote application that links back to the local application. For example, Confluence is linked to Jira, but Jira does not have a reciprocal link back to Confluence.
  • Check that the link exists on the remote application. If it doesn't exist you should create it.
  • Reset the OAuth authentication for both the incoming and outgoing connections of the application link. See OAuth security for application links.

  • If none of the above actions help, delete the application link at both ends and then recreate it.

Back to top

 

 

OAuth signature rejected

The local application was unable to authenticate with the remote application.

You may see this error message in the Atlassian application logs:

oauth_problem=signature_invalid
Possible causes
Actions you can take
The application URL for the link does not match the URL that the remote application is reporting.
  • Check that the base URL for the remote application is the same as the application URL defined in the link.
  • If using a reverse proxy or port forwarding, check that the "Host" header is reporting the correct host name or port.
  • If using a reverse proxy or port forwarding, check that the applications are correctly configured for use with a reverse proxy.
Misconfigured proxy or server.xml for the application.

Check that the proxy and the application both use the same protocol (that is, HTTP, or HTTPS):

  • Does the application's server.xml file specify the same protocol as the proxy? Look for the scheme attribute in the Tomcat SSL connector directive.
  • Was there a recent upgrade that could have caused a configuration change?

Check our Reverse proxy troubleshooting guide.

See also: OAuth error oauth_problem=signature_invalid

Back to top

 

 

The system clocks are not synchronized

The application link was attempting to authenticate with the remote application but the timestamps from the local and remote machines do not match. This prevents the applications from authenticating with each other.

You may see this error message in the Atlassian application logs:

oauth_problem=timestamp_refused
Possible causes
Actions you can take

The system clocks are not synchronized because of:

  • an incorrectly set time zone on at least one application
  • substantial differences in the time between the two servers.
  • Synchronize the system times.
  • Set up ntpd to keep the clocks in sync.
  • Set up a network time server to keep the clocks in sync.
  • Check that time zone definitions are provided by each operating system.

Back to top

 

 

OAuth token rejected

The application link was attempting to authenticate with the remote application but the OAuth token was rejected.

You may see this error message in the Atlassian application logs:

 oauth_problem=token_rejected
Possible causes
Actions you can take
The user has established an OAuth token before, but sometime later revoked the token on the remote end.
  • Re-authenticate to get a new token. This should happen the next time an application requires user authorization. After this warning appears once, the token will be discarded and the user will be prompted to re-authenticate.

Back to top


 

 

OAuth mismatch

The application link was attempting to authenticate with the remote application but the OAuth configuration is not the same at both ends of the application link. For example, if you wish to use impersonation, then both the local and remote ends of the link must be set to use impersonation.

See OAuth security for application links.

Back to top

 

 

Unsupported OAuth level

The application link was attempting to authenticate with the remote application but the OAuth level configured for the link does not support all the available integration features. For example, your team can't see the details dialogs for the Development panel in Jira Software issues.

You need to update the application link to use 2-legged OAuth for the link.

See OAuth security for application links .

Back to top

 

 

 

Access denied

You are logged in to the local application using an account that does not have admin permissions on the remote application. If you don't have such an account, you may be able to:

  • Obtain temporary admin permissions for the remote application.
  • Find someone in your organization who does have such an account who can complete the task for you.

See OAuth security for application links.

Back to top

 

Error messages in the logs

You may see these error messages in the application logs:

Follow a link above to see detailed information on this page.

Application log locations

Logging configurationApplication logsTomcat webserver logs
Bamboo <Bamboo installation directory> /logs  
Bitbucket Server / Stash

<Bitbucket home directory>/log

<Stash home directory>/log

<Bitbucket Server installation directory>/logs

<Stash installation directory>/logs

Confluence <Confluence home directory>/logs <Confluence installation directory >/logs
Crowd <Crowd home directory>/logs <Crowd installation directory>/apache-tomcat/logs
Crucible <Crucible installation  directory>/var/log/  
Fisheye <FishEye installation  directory>/var/log/  
JIRA applications <JIRA application home directory>/log <JIRA application installation directory>/logs

Consider enabling the DEBUG level of logging on the application to get more detailed logs – DEBUG adds all stack traces, and includes HTTP response messages.

 

  • No labels
 




 

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.