Identity Provider Event Log
The Identity Provider Event Log is the Salesforce Setup view that surfaces audit events related to the org acting as an Identity Provider for federated SSO scenarios.
Definition
The Identity Provider Event Log is the Salesforce Setup view that surfaces audit events related to the org acting as an Identity Provider for federated SSO scenarios. When Salesforce is configured as the SAML or OpenID Connect Identity Provider for downstream applications (or for other Salesforce orgs through Environment Hub), every authentication event produces a log entry: successful logins, failed logins, error responses, and configuration changes. The log is the canonical audit artifact for SSO-related security investigations.
The log appears in Setup > Identity > Identity Provider Event Log. Each entry captures the timestamp, the relying party (the application or org that requested authentication), the user, the event type, and any error message or status code. Retention follows the standard Salesforce log retention windows; for longer-horizon audit, export to a SIEM through Event Monitoring or scheduled extract. The log is read-only for administrators; events cannot be deleted or modified through the standard UI.
How the Identity Provider Event Log captures SSO events
When Salesforce is the IdP
Salesforce can act as the Identity Provider for any SAML or OIDC relying party: a third-party SaaS app, an internal application, or another Salesforce org. The configuration lives under Setup > Identity > Identity Provider. Once Salesforce is the IdP and at least one Service Provider is configured, the platform logs every SAML or OIDC request and response. This is distinct from Salesforce-as-Service-Provider (where another IdP authenticates Salesforce users), which uses a different log surface.
Event types captured
The log captures several event types. Login successful: user authenticated and a SAML assertion or OIDC token was issued. Login failure: the request reached Salesforce but authentication failed (invalid user, locked account, missing permission). Configuration change: an admin modified the Connected App or SAML settings. Service Provider registered/removed: a new SP was added or removed. Each event type has a distinct status code; build alerts on suspicious patterns.
What an entry contains
Each log entry has: Timestamp, Username (the Salesforce user being authenticated), Service Provider (the relying party), Identity Provider Initiated flag (whether the flow started from Salesforce or from the SP), Status (success or specific error code), and Details (error message or additional context). The Details field is the most useful for troubleshooting; specific error codes map to specific causes (signature mismatch, audience restriction failure, etc.).
Common troubleshooting scenarios
When SSO fails for a downstream app, the Identity Provider Event Log is the first stop. Common findings: a missing required field in the SAML assertion (the SP expects something the IdP did not send), a clock skew issue between IdP and SP, an audience restriction not matching, or a Connected App that has been disabled. The log entry usually points clearly to the cause, saving hours of speculative debugging.
Retention and Event Monitoring
Default retention for the log varies; events typically remain available for several months but not forever. For longer-horizon audit (the kind compliance teams expect), Event Monitoring provides export to external SIEMs. The log is one of many event types under Event Monitoring; enable export to capture full audit history. Without Event Monitoring, you are limited to the retention window of the Setup view.
Permissions to view the log
Viewing the Identity Provider Event Log requires the View Setup and Configuration permission. Modifying SSO configuration requires additional permissions (Manage Connected Apps). Audit who has these permissions; access to the log itself is not sensitive, but the configuration permissions that admins typically also hold are very sensitive. The log can implicate users; treat queries against the log under standard audit data handling.
Security investigation use cases
The log is critical during incident response. A reported account compromise prompts a query for all SSO logins for that user in the relevant time window. A suspected misuse of an integration prompts a query for all logins from the integration's Connected App. The log answers "who logged into what when through SSO" with authoritative timestamps. Capture screenshots or export specific events as part of incident documentation.
Use the Identity Provider Event Log for troubleshooting
Using the Identity Provider Event Log effectively combines knowing when to look at it (every SSO troubleshooting and security investigation) and how to extract data from it (filtering, exporting, alerting). The steps below cover both.
- Open the log
Setup > Identity > Identity Provider Event Log. The page lists events in reverse chronological order.
- Filter to the scenario
Use the column filters to narrow by user, Service Provider, event type, or status. Most troubleshooting starts with a specific user and time window.
- Read the Details field
Click into a specific event to see the Details field. Error messages here are usually specific enough to identify the cause directly.
- Cross-reference with SP-side logs
For SSO troubleshooting, the IdP log shows what Salesforce sent. The SP-side log shows what the SP received and how it interpreted. Compare to identify mismatches.
- Export for incident response
For security investigations, export the relevant events as part of the incident documentation. The standard list view export covers small volumes; Event Monitoring covers larger.
- Set up alerts (with Event Monitoring)
For real-time detection, build SIEM alerts on Event Monitoring data for patterns like repeated SSO failures or successful logins from unexpected SPs.
- Schedule regular log review
Add a recurring review for any orgs running Salesforce as the IdP for multiple SPs. Pattern changes in the log often surface misconfigurations or pending issues.
Narrow log to a specific Salesforce user. The starting point for user-specific troubleshooting.
Narrow to a specific Connected App. Useful when one downstream app is failing while others work.
Login success, login failure, configuration change. Focus on failure events for troubleshooting.
Long-horizon export to external SIEM. Required for compliance-grade audit retention.
Combine IdP log and SP-side log to identify configuration mismatches.
- The log covers only Salesforce-as-IdP scenarios. Salesforce-as-SP logins show in Login History; do not confuse the two.
- Default retention is limited. Without Event Monitoring, the log may not preserve far enough back for compliance investigations.
- Events cannot be deleted or modified. The log is read-only; document by screenshot or export for any preservable evidence.
- Some SP-side errors are not visible in the IdP log because they happen after Salesforce sent the assertion. Compare with SP-side logs for the complete picture.
- Failed SSO attempts that did not reach Salesforce produce no IdP log entry. Network-level failures, DNS issues, or SP-side errors before contacting the IdP are invisible here.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the primary benefit of Identity Provider Event Log for Salesforce administrators?
Q2. Can a Salesforce admin configure Identity Provider Event Log without writing code?
Q3. Why is understanding Identity Provider Event Log important for Salesforce admins?
Discussion
Loading discussion…