Skip to main content

Decision audit and logs

Every authorization decision on SecureAuth Connect is auditable. This page covers what is recorded, where to find it, and how to trace a specific allow or deny when you need to explain an outcome or debug a surprising denial.

What is recorded​

SecureAuth records three kinds of signals that together tell you why a decision happened:

  • Policy change events. Every policy create, update, publish, or delete action is logged, with the actor, timestamp, and the before-and-after state. Policy changes are always auditable even if no decision has run against the new version yet.
  • Decision events. Each policy evaluation that affects a token issuance, consent, scope grant, or API request is logged with the decision outcome and the inputs the policy saw.
  • Authorization server events. Token issuance, consent, and scope grant events carry the decision outcome and a reference back to the policy that produced it.
Product-specific schema

Exact decision log field names vary by deployment. Use the fields you see in your tenant's audit logs as the source of truth, and consult Audit logs for the full event reference.

Where to find decisions​

Audit logs​

The primary audit surface is the workspace audit log. It captures policy change events and authorization server events such as token issuance, consent, and scope grant. See Audit logs for viewing, filtering, and export options.

Authorizer decisions​

Runtime decisions made by a gateway or mesh authorizer are logged by the authorizer itself. The exact location depends on the platform:

  • Gateway-native logs (Kong, Apigee, AWS API Gateway, Azure API Management) capture the authorizer's allow or deny at the request level.
  • Service mesh authorizers (Istio) emit decisions through the mesh's access log pipeline.
  • The standalone authorizer writes decisions to its own log output, which you can ship to your existing log sink.

For the integration-specific log format, see the relevant authorizer integration guide.

When a decision is made at token time, the outcome is visible in two places:

  • The issued token itself reflects what was allowed, through the scopes, claims, and RAR details it carries.
  • The consent and session history shows what the user approved and under which policy.

Tracing a specific decision​

Use this sequence when you need to explain why a particular request was allowed or denied:

  1. Identify the enforcement point. Was this at the authorization server, a gateway, a mesh, or a standalone authorizer? The reader sees one layer; the decision may have been made upstream.
  2. Find the correlated event. Match the request by user identifier, client identifier, timestamp, and request correlation ID if one is present.
  3. Read the attached policies. List the policies attached at that enforcement point for the subject type involved. See Policy scope and attachment for how attachment maps to subject.
  4. Replay the inputs. Use policy testing and simulation to re-run the same policy against a reconstructed input and see which validator produced the outcome.

Debugging surprising denials​

Most surprising denials fall into a short list of root causes:

  • Wrong attachment point. The policy runs at a different layer than the one the reader expected. Check whether the attachment is at workspace, application, scope, or API level.
  • Subject-type mismatch. A policy applies only to human users but the request came from a machine client, or the reverse. See Subject targeting.
  • Missing claim or attribute. The policy reads a claim or authentication context attribute that was not populated for this user. Check identity pool attributes and the token claim mapping.
  • External data not available. A Rego policy called an external endpoint that timed out or returned an unexpected value.
  • Scope or RAR not requested. The client did not request the scope or RAR details the policy expected to see in the request.

For each root cause, policy testing and simulation lets you reproduce the failure with a sample input and confirm the fix before you publish.

See also​