Should organisations keep IdP logs and authorization logs separate?

Why This Matters for Security Teams

Identity provider logs and authorization logs answer different audit questions, and mixing them usually creates a false sense of coverage. An IdP record can show that a user authenticated, that a session was issued, or that an account state changed. An authorization record shows whether a specific application action was allowed, denied, or escalated, and why that decision was made. If those trails are blended together, access reviews become harder to prove and control testing becomes easier to misread.

That separation is especially important when teams need to explain a control failure after the fact. Authentication evidence alone does not prove that a sensitive action was permitted for the right reason, and application decision logs alone do not prove that the actor was actually authenticated at the time. Auditors, incident responders, and access reviewers need both views, but they need them as distinct records so they can reconstruct the sequence cleanly.

In practice, many teams discover the gap only after a failed access review or an incident investigation has already exposed the missing evidence chain.

How It Works in Practice

Keeping the logs separate does not mean keeping them disconnected. The practical pattern is to preserve each log type at its own layer of responsibility, then correlate them through shared identifiers such as user ID, session ID, request ID, timestamp, or transaction ID. The IdP should record authentication events, account lifecycle events, MFA prompts, token issuance, and session creation or revocation. The application should record authorization outcomes, policy decisions, resource names, action names, and the policy inputs that drove the decision.

This division helps because the failure modes are different. If authentication is the issue, the IdP trail is usually the first place to confirm account compromise, token abuse, or abnormal login patterns. If the issue is overbroad access, the application authorization trail is the place to prove whether the policy logic, role assignment, or conditional rule caused the decision. A joint record can still exist in your SIEM or analytics layer, but that should be a derived view, not a replacement for the original evidence.

• Use IdP logs to prove who authenticated, when, from where, and under what account state.
• Use authorization logs to prove what action was requested, whether it was allowed, and which rule or policy path applied.
• Correlate the two for investigations, but keep the source systems authoritative for their own decisions.

For access-control testing, this separation also makes it easier to prove least privilege, detect inconsistent policy behaviour, and show whether a denial was caused by missing authentication, missing authorization, or both. These controls tend to break down when applications rely on the IdP as a proxy for authorization evidence, because authentication success can be mistaken for access approval.

Common Variations and Edge Cases

Tighter logging boundaries often increase operational overhead, so organisations have to balance clarity against correlation effort. The standard answer can shift a little in environments where the IdP also acts as the policy engine, but even then the authentication trail and the authorization decision trail should remain distinguishable as separate evidence sets.

One common edge case is SSO-heavy environments, where teams assume the IdP log is enough because the login was centralized. It usually is not. Centralized authentication does not eliminate application-level authorization, and many of the most important decisions happen after the user is already authenticated. Another edge case is API traffic, where the caller may be a workload, service, or integration rather than a human. The logging principle is the same: the record that proves authentication or token issuance is still different from the record that proves the application allowed a specific action.

Best practice is to keep the source trails separate, normalize the fields you need for correlation, and avoid building audit processes on a single blended log stream. That gives you better evidence quality without forcing teams to manually reconcile unrelated event types every time they investigate access.

Practitioner Guidance

What to verify: Confirm that an IdP log can independently answer authentication, account state, and session questions, while the application log can independently answer authorization questions. If one trail is being used to stand in for the other, the audit story is probably incomplete.

Decision rule: If the control question is “Did the user prove who they were?”, inspect the IdP trail first. If the control question is “Why was this action permitted or denied?”, inspect the authorization trail first. Do not collapse those into one evidentiary step.

Practitioner takeaway: Separate logs are not an administrative preference, they are what makes access evidence trustworthy enough to support audits, investigations, and control testing.

Related resources from NHI Mgmt Group

• Should organisations keep the IdP in the authorization path?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?