Is your feature request related to a problem?
A FAILED_LOGIN audit event can lose the identity that was presented when authentication rejects credentials before creating a trusted User. In that case, audit_request_effective_user is correctly recorded as , but an investigator cannot determine which principal was attempted.
For example, #6494 rejects a validly signed JWT whose subject uses a reserved security prefix. The centralized audit event records FAILED_LOGIN with effective user , while the attempted subject and rejection reason appear nowhere as structured audit fields. Relying on an application WARN or a raw JWT retained in request headers makes correlation difficult and can expose credentials.
What solution would you like?
Add an optional audit_request_attempted_user field for failed authentication events. This field would contain the candidate principal presented by the credential while preserving audit_request_effective_user as until authentication succeeds.
For the reserved JWT subject scenario:
- audit_category remains FAILED_LOGIN.
- audit_request_effective_user remains .
- audit_request_attempted_user contains the rejected JWT subject.
- The event is emitted once by the centralized authentication-failure path.
- No raw token or other credential is included to make this field available.
Values should be length-bounded and safely serialized because attempted identities are not trusted input. The behavior and privacy implications should be documented, and audit filters should be considered where operators may not want attempted identities retained.
A complementary structured failure-reason field, such as audit_authentication_failure_reason: RESERVED_SUBJECT_PREFIX, would make the event more useful, but it can be designed independently.
What alternatives have you considered?
- Store the attempted identity in audit_request_effective_user. This is misleading because authentication did not establish that identity.
- Audit directly from individual authenticators. This risks duplicate FAILED_LOGIN events and inconsistent fields.
- Rely on application WARN logs. These may be routed separately and lack a reliable audit correlation identifier.
- Recover the subject by decoding a JWT from audit_rest_request_headers. Audit logs should not retain raw bearer tokens, especially when a custom JWT header is configured.
Do you have any additional context?
Discussion: #6494 (comment)
Integration coverage added in #6494 confirms the current event has audit_request_effective_user: and no initiating user, roles, or authentication method.
Is your feature request related to a problem?
A FAILED_LOGIN audit event can lose the identity that was presented when authentication rejects credentials before creating a trusted User. In that case, audit_request_effective_user is correctly recorded as , but an investigator cannot determine which principal was attempted.
For example, #6494 rejects a validly signed JWT whose subject uses a reserved security prefix. The centralized audit event records FAILED_LOGIN with effective user , while the attempted subject and rejection reason appear nowhere as structured audit fields. Relying on an application WARN or a raw JWT retained in request headers makes correlation difficult and can expose credentials.
What solution would you like?
Add an optional audit_request_attempted_user field for failed authentication events. This field would contain the candidate principal presented by the credential while preserving audit_request_effective_user as until authentication succeeds.
For the reserved JWT subject scenario:
Values should be length-bounded and safely serialized because attempted identities are not trusted input. The behavior and privacy implications should be documented, and audit filters should be considered where operators may not want attempted identities retained.
A complementary structured failure-reason field, such as audit_authentication_failure_reason: RESERVED_SUBJECT_PREFIX, would make the event more useful, but it can be designed independently.
What alternatives have you considered?
Do you have any additional context?
Discussion: #6494 (comment)
Integration coverage added in #6494 confirms the current event has audit_request_effective_user: and no initiating user, roles, or authentication method.