You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

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

 

Error messages in the logs

You may see these error messages in the application logs:

Follow a link above for 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.

 

 

What is OAuth?

OAuth is an open standard for authorization between applications. Instead of sending credentials between applications (which can be compromised), OAuth uses tokens generated on behalf of a user to authenticate against a remote application.

We don't recommend using the Trusted Applications or Basic Access authentication types anymore. We recommend that you use OAuth authentication for application links, because of the greater security inherent with that protocol.

See OAuth security for application linksfor more information.

Authorization can be granted in one of several ways:

3-legged OAuth (3LO)

3LO is the default flavour of OAuth. The user must manually grant access to an application. In Atlassian applications, this behaviour shows up when you see a "Click here to authenticate" link. Users will only need to approve an application once.

For a great introduction to how 3-legged OAuth works behind the scenes, see this introductory blog.

2-legged OAuth (2LO)

2LO makes requests anonymously. In cases where a user's authorization is required, one of the following methods will be used:

  • 2LO with "Execute As": all requests that require a specific user's authorization will be executed as the configured user.
  • 2LO with impersonation: users are automatically authorized on the other application, without needing to explicitly authenticate. 
  • No labels
 




 

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