SSO login logs

SSO Logs records every single sign-on attempt made through your identity provider: who made it, from where, and how it ended. Use it when someone cannot sign in, or when you need the exchange behind an attempt. It sits in the Logs tab of Observability; Audit, sign-in and notification logs covers the Audit and Notifications sub-tabs.

Open the SSO login logs

In the sidebar, open Observability, then click Logs.
Click SSO Logs.
Set Period, then search or filter the columns.

The sub-tab appears only if your role includes it, and a sub-tab that turns out not to be permitted falls back to Audit. You need View Audit Log to open Logs at all. See Permissions.

What the table shows

Each row is one sign-in attempt through SSO, successful or failed.

Column	What it shows
Date & Time	When the attempt happened.
Status	success in green, or failed in red.
Email	The email address the attempt carried.
Name	The name from the provider record.
IP Address	Where the attempt came from.
User Agent	The browser that made the attempt.
User ID	The account's numeric id, when present.
Session ID	The identifier of this record.
Error Code	On a failed attempt, a short code. The badge is always shown in the danger tone.
Error	The platform's note about the failure.
IdP Error	The error your identity provider returned.
IdP Error Description	The description that came with it.

IdP stands for identity provider. Your column layout is remembered in this browser.

What the statuses and error codes mean

Status is success or failed. A successful row carries no error details. A failed row carries one code from this set, and the Error column carries the platform's note for it:

Code	What it records
`access_denied`	The identity provider did not grant access: the person cancelled at the provider, or the provider refused the request.
`invalid_state`	The attempt could not be matched to a sign-in this platform started.
`domain_not_allowed`	The email address domain is not in the allowed domains of the SSO configuration.
`sso_misconfigured`	There is no active SSO configuration, so SSO cannot be used.
`account_inactive`	The account matching this email address is deactivated.
`email_unverified`	The identity provider reported the email address as unverified.
`sso_failed`	The sign-in could not be completed; the surrounding error text carries the detail.

The person signing in sees the sign-in page's own wording, not these codes. The connection they used is set up in Single sign-on (SSO).

Investigate a failed sign-in

Open Observability > Logs > SSO Logs.
Set Period to cover the attempt, then filter Status to failed, or filter Email to the person who reported the problem.
Click the row to open its details on the right; click the row again to close them.
Read the Error section. When the identity provider returned its own error, a line under the message starts with Identity provider:.
Use Show 5 more to reveal the rest of the session rows, and open Authorization request and ID token claims to see the exchange.

Read one record in detail

The panel opens with the Session section: Provider, Email and When. Provider shows only the host of the identity provider's address, for example login.microsoftonline.com. Show 5 more adds Name, User ID, Session ID, IP address and User agent; Show less collapses the section again.

Below the session rows:

The Error section appears only after a failure. It shows the platform's message, or No message when none was recorded, and the provider's text after Identity provider: when there is one.
Authorization request and ID token claims are collapsible sections holding what was sent to the provider and what it returned; the claims section keeps only a fixed set of token claims, never the token itself. A value that was not stored reads Not recorded.

Email and Session ID have a copy control beside them; the check mark clears after two seconds. Close the panel with Close details.

Export the log

Set Period, and filter or search as needed.
In the export control in the toolbar, pick CSV, Excel, JSON or TSV, then click the download icon next to it.

The export contains every row that matches your period, filters, sorting and search, and the file is named sso_login_logs. The export control appears only with Export SSO Login Logs. The shared download rules, including the row cap, are on Periods, filters and exports.

Periods and limits

The Period control offers Today, Last 7d, Last 30d and Custom, and starts on Last 7d.
A custom range can span at most one year. A longer range is refused with Date range too large and the message Custom date range cannot exceed 1 year.
Rows per page starts at 50; you can pick 50, 100 or 200.
If the log cannot load at first, it shows Failed to load SSO login logs with the reason and a Retry button. A later failure keeps the rows and your search, and shows an error bar with Retry; a failed refresh reads Refresh failed, a failed export reads Export failed, and a column filter that cannot load its values reads Filter options failed. See Observability troubleshooting.

Permissions

To do this	You need
Open the Logs tab	View Audit Log
See the SSO Logs sub-tab and read the log	View SSO Login Logs, preset SSO Login Log Viewer
Export the log	Export SSO Login Logs

The SSO Login Log Viewer preset is included in both Observability Administrator and Observability Viewer. The Observability Viewer preset does not include exporting, so exporting needs the Export SSO Login Logs permission. Presets are assigned in Roles and permissions, and the full list is in the Permission reference.

Questions, answered

Why can't I see the SSO Logs sub-tab?

The sub-tab needs View SSO Login Logs, and the Logs tab needs View Audit Log. A sub-tab your role does not permit falls back to Audit. Ask an administrator for the SSO Login Log Viewer preset; see Roles and permissions.

A user says they cannot sign in. How do I find out why?

Open Observability > Logs > SSO Logs, set Period to cover the attempt, and filter Email to the person or Status to failed. Open the record: the Error Code, Error and IdP Error Description fields say what was recorded, and the Error section carries the provider's own text when it returned one.

What do the error codes mean?

The table above lists each code and what it records. A code always comes with the platform's Error text, and with the provider's IdP Error and IdP Error Description when the provider returned them.

Why does a record show no Error section?

The Error section appears only on failed attempts. A successful attempt needs none, and the rest of its details still show the session and the exchange.

Why do the Authorization request and ID token claims sections read Not recorded?

The platform stores those parts of the exchange when it has them; a value it did not store for that attempt reads Not recorded. The Error and IdP fields still tell you how the attempt ended.

Why is the Export control missing on the SSO log?

Exporting needs Export SSO Login Logs. It is a separate permission, so a role that can read the log may still lack it. Ask an administrator to add it; see Roles and permissions.

What does the Provider row show?

Only the host of the identity provider's address, not the full address, for example login.microsoftonline.com. The fuller values sit in Authorization request.

What is the difference between Error, IdP Error and IdP Error Description?

Error is the platform's own note about the failure. IdP Error and IdP Error Description are the error and the description your identity provider returned. When the provider returned nothing, those two stay empty.

Can I copy an email address or a session ID?

Yes. In the details, the Email and Session ID rows have a copy control; the check mark clears after two seconds.

What does the Session ID identify?

It is the identifier of this log record, shown for each attempt. Copy it from the details when you need to point a colleague to one attempt.

Can a problem with this log stop someone signing in?

No. Logging never blocks a sign-in: if a record cannot be written, the sign-in completes as usual, and the platform notes the failed write on its side.