Guard oauth_application_created audit event on persisted? in CreateService

SAM FIGUEROArequested to merge
duo/fix/618476-false-oauth-application-created-audit-event into master

What does this MR do and why?

EE::Applications::CreateService#execute was auditing an oauth_application_created event even when the OAuth application failed validation and was never persisted. The guard only checked for a present entity (owner || current_user), not whether the record was actually saved.

This adds application.persisted? to the guard, matching the pattern already used in the sibling services:

  • EE::Authn::Applications::UpdateService: next unless application.persisted? && application.errors.empty?
  • EE::Authn::Applications::DestroyService: next unless application.destroyed?

Because these events are emitted with streamed: true, false positives could propagate to external SIEM/audit destinations, not just the internal audit log.

Root cause: The super.tap guard only checked for a present entity, so an unsaved/invalid record still triggered an audit call.

Scope: Only the create audit path is affected. Update and destroy overrides live in a different namespace (EE::Authn::Applications::*) and already guard correctly.

References

Screenshots or screen recordings

N/A - no UI changes.

How to set up and validate locally

  1. In a Rails console or spec, call Applications::CreateService.new(user, request, invalid_params).execute with params that fail validation (e.g. blank redirect_uri).
  2. Confirm no oauth_application_created audit event is created.
  3. Call with valid params and confirm the audit event is still created.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports