Audit Logging 

The Jira and Confluence audit log holds records of key activities, such as adding new users, changing group memberships and many other.
Read more about it here: 
https://confluence.atlassian.com/adminjiraserver/auditing-in-jira-938847740.html 
https://confluence.atlassian.com/doc/auditing-in-confluence-829076528.html

Default Audit Logging

Since version 1.1.0, creating and deleting tokens (both deleting a single token or all for a user as an admin) is already always added to the audit log:

Advanced Audit Logging

Starting with version 1.5.0, sys-admins have more control over what events should be added to the audit log.

Please consider carefully what type of authentication events you want to audit-log.
Depending on the amount of REST requests and the event types, the audit log size might increase very quickly.
Having a long audit log retention period combined with a lot of recorded events may affect your database and its performance.

You can select the events to be logged in Audit Logging tab. All these are turned off by default.

1. Successful Authentication
2. Failed Authentication Attempts
   1. Audit-log failed API token authentication attempts
   2. Audit-log all failed authentication attempts
3. Permission Denied
   
   

Examples

With 1 - Successful Authentication - activated, a successful authentication with an API token is recorded into the audit log.
Because of technical limitations, the author is shown as "Anonymous".  
The "Affected object(s)" column however is showing the reference to the user who logged in.

Option 2 - Audit-log failed API token authentication attempts - a) is only available, if basic authentication with regular passwords is disabled.
A valid API token is expected and if this is not the case, an audit record like the below is created.

It also includes logging of attempts coming from an IP address which is restricted by the app:

With 2 b) - Audit-log all failed authentication attempts - activated, a lot of other API interactions with regular passwords might be recorded,
since there is no way to tell for certain, if the authentication header contained a password or an API token.
Thus, it might lead to a lot of events being recorded and is usually not advised.






With 3 - Permission Denied - activated,
using tokens with "Read Only" scope for a write operation will result in a record like the below:

Audit Logging in Confluence

It seems that Confluence is showing the client IP address in the Load balancer/proxy IP address field and reverse.
This is already the case for audit-log records not created by the API Token app and seems to be a Confluence issue.

Logfile

After changing the log level for the package de.resolution.apitokenauth to INFO
Jira: https://your-jira/secure/admin/ViewLogging.jspa / read here on how make the log level persistent
Confluence: https://your-confluence/admin/viewlog4j.action / read here on how make the log level persistent

you'll see the following authentication-related entries in the log file of Jira or Confluence. The entry contains:

• a description of the event
• the token description (if applicable for the event)
• the token scope (if applicable for the event) 
• the username
• the path of the REST endpoint for the call

Successful Authentication

Failed Authentication Attempts

Only if basic authentication with a regular password is disabled in the app settings, it's safe to tell if a token provided was wrong, causing the below message in the log file:

Another reason for a failed authentication attempt might be an IP restriction:

If basic authentication with a regular password is enabled, it might still be a valid password which is accepted by the Jira- or Confluence password authenticator. Hence, the log message reads like this:

Permission Denied Events

If a token with a "Read Only" scope is used during a write operation, a 403 error is returned as REST response and leaving a log file entry like the below.
Other 403 errors logged by de.resolution.apitokenauth.ApiTokenAuthenticationService should only occur in rare events.