Important Update Effective February 1, 2024!
Due to recent changes in Jira and Confluence, we've made the tough decision to discontinue the OpenID Connect (OIDC)/OAuth app and no longer provide new versions for the newest Jira/Confluence releases as of January 31, 2024.
This is due to some necessary components no longer shipping with Jira/Confluence, which would require some extensive rewrites of the OIDC App.
Troubleshooting
Logging
To gather some more details about what is going on when accessing the REST API with the app enabled.
The logging level can be refined in the following way:
As an administrator, navigate to the Logging and Profiling section and add the package and logging level below.
Once added, the app starts logging more content to
<JIRA home directory>/log/atlassian-jira.log
<Confluence home directory>/log/atlassian-confluence.log
Jira
Click on the Configure logging level for another package. link in the Default Loggers section
Confluence
In Confluence you can enter the package name directly, set the debug level and click on Add entry.
With logging only set to INFO, you'll be able to see all authentication attempts on the REST API:
2020-02-20 12:20:13,418+0000 http-nio-8080-exec-15 INFO anonymous 740x3522x1 - 91.41.231.119,100.100.0.6 /rest/api/2/myself [d.resolution.apitokenauth.ApiTokenAuthenticationService] Found a matching token for authenticating user admin, created on 1582191421157. REST endpoint: /rest/api/2/myselfUsers providing an expired or invalid token or even just a regular password will cause a log entry like this:
2020-02-20 12:21:38,689+0000 http-nio-8080-exec-13 INFO anonymous 741x3529x1 - 91.41.231.119,100.100.0.6 /rest/api/2/myself [d.resolution.apitokenauth.ApiTokenAuthenticationService] User admin tried to authenticate with an invalid token or a regular password. Passing the request further to the default authenticator. REST endpoint: /rest/api/2/myselfSetting the logging level to TRACE will reveal even more details but this should never be required unless when asked for by our support.
Debugging IP Range restriction issues
With debug logging changed to TRACE as per above instructions, you'll see why a client request was rejected
because of some invalid IP range restriction and/ or reverse proxy settings.
Below example shows that the trusted reverse proxy IP (172.31.54.38) didn't match the one provided (172.31.24.155). (Line 1)
Hence, the client IP won't be read from the header provided in the configuration. (Line 2)
If you've provided an IP restriction to only allow let's say 87.173.217.95, the check will fail and reveal the address of the reverse proxy instead. (Line 3)
Make sure it is really one of your trusted proxies and add this IP as trusted reverse proxy IP.
2020-06-09 09:42:23,111 http-nio-8080-exec-23 TRACE anonymous 582x1905x1 - 87.173.217.95,172.31.54.38 /rest/api/2/myself [d.resolution.apitokenauth.ApiTokenAuthenticationService] Trusted IP address or range 172.31.24.155 contains reverse proxy IP address 172.31.54.38 = false
2020-06-09 09:42:23,111 http-nio-8080-exec-23 DEBUG anonymous 582x1905x1 - 87.173.217.95,172.31.54.38 /rest/api/2/myself [d.resolution.apitokenauth.ApiTokenAuthenticationService] None of our trusted reverse proxy IP addresses matched the one from the request. Won't read real client IP from request.
2020-06-09 09:42:23,129 http-nio-8080-exec-23 DEBUG anonymous 582x1905x1 - 87.173.217.95,172.31.54.38 /rest/api/2/myself [d.resolution.apitokenauth.ApiTokenAuthenticationService] Remote address 172.31.54.38 is not in range