Single Sign-On
ShadowMap discovers every Single Sign-On (SSO) and identity-provider integration embedded in your public web applications, attributes each one to a provider and account/tenant identifier, scores its redirect and protocol security, and gives you a triage workflow to approve known integrations or flag rogue ones. It answers a question most teams can't answer from the inside: which authentication endpoints actually exist on my external attack surface, and are any of them shadow IT, deprecated, or misconfigured?
Overview
The page is a flat, paginated table — one row per detected SSO login configuration (a sso_login_pages record), not one row per provider. A single provider such as Azure AD or Okta can appear many times if it is wired into multiple applications, with multiple account/tenant IDs, or with multiple redirect URIs.
At the top of the page you get:
- A metrics strip (six KPI cards) summarising provider count, triage backlog, insecure configurations, and coverage.
- An analytics panel with a Provider Distribution bar chart and a 30-day Detection Trend line chart (toggle it from the header).
- Status tabs — Needs Review, Approved, Unauthorized, All — with live counts.
- A filter bar, a Bookmarked quick toggle, and Export.
Each row carries the provider (with favicon), the account ID, the application it was found on, the redirect URI, a security verdict, a risk level, a review status, and first/last-seen timestamps. Clicking a row opens a detail drawer; the Open full page link in the drawer opens the full provider detail view with per-account, per-application, and per-redirect breakdowns.
How it works
The mechanics below are not visible in the UI but determine what you see and how counts are derived.
Where the data comes from
SSO records are a byproduct of ShadowMap's web-application crawl, not a separate scan. When the crawler renders a discovered web application, it identifies authentication endpoints and SSO buttons/redirects (OAuth 2.0, OpenID Connect, SAML, and similar protocols), then extracts the provider, the account/tenant/client identifier embedded in the integration, the redirect URI, and the favicon. Each detection is stored as one sso_login_pages row tied to the application (http_app_id) and the scan session it was seen in. Because detection rides on the web-app crawl, an SSO record only exists for applications ShadowMap has already discovered and crawled — see Web Applications.
What "live" means (and why counts can differ from the raw table)
Every list, KPI, and provider-detail query is scoped to your most recent completed scan. A record is counted only when:
- its
last_seen_onis at or after the latest scan's start date (it was re-observed in the current scan), and - the parent application's status is open, reopened, or newly-discovered — closed/retired applications are excluded.
This is why a provider that was decommissioned shows up only until the next scan no longer finds it, and why the page reflects your current surface rather than all-time history.
Risk Level
Each row gets a risk_level derived from its redirect URI — this is a fast structural heuristic, independent of the deeper security verdict below:
| Risk | Trigger | Why it matters |
|---|---|---|
| Critical | Redirect URI uses http:// (cleartext) | Authorization codes/tokens can be intercepted in transit |
| High | Redirect URI contains a wildcard (*) | Open-redirect / token-leak surface in the OAuth flow |
| Low | HTTPS redirect with no wildcard | No structural redirect weakness detected |
Security verdict (goblin analyzer)
Separately from the redirect heuristic, ShadowMap's SSO assessment (internally, the goblin analyzer) inspects each configuration and writes a security_status plus a list of structured findings. This is the column that surfaces real protocol-level weaknesses — implicit OAuth flow, missing PKCE/state, cleartext or wildcard redirects, weak SAML configuration, and similar checks. MFA presence is recorded when detectable.
| Security badge | Meaning |
|---|---|
| Insecure (red) | A high/critical misconfiguration was found |
| Weak (amber) | Only low/medium findings |
| Secure (grey) | Assessed, no material findings |
| Not Applicable (grey) | Assessment doesn't apply to this configuration |
| Not Assessed (muted) | Not yet evaluated |
The list badge shows the verdict plus a finding count (e.g. Insecure · 3); hover to see the finding titles. Per-finding severity is ranked critical > high > medium > low > none, and the provider detail page rolls findings up across all of that provider's records, deduplicated by check ID, and reports the single worst severity.
Review status is per provider, not per row
When you Approve, Flag, or Reset, the status change is applied at the provider level — the backend updates every detection row that shares that provider name for your company — so a verdict on Okta applies to Okta everywhere it appears. Status values are needs_review (default), approved, and unauthorized. The Needs Review / Approved / Unauthorized tab counts in the strip count distinct providers per status, while the All tab and most filters count individual detection rows.
Why this matters
| Use case | What to look for |
|---|---|
| Shadow IT discovery | Any provider your IT/identity team doesn't recognise. A Google Workspace or Okta integration on a microsite nobody owns is unmanaged SaaS. |
| Deprecated endpoint risk | Old IdPs that should have been decommissioned (e.g. legacy ADFS after an Azure AD migration). A live login endpoint bypasses current MFA/conditional-access policy. |
| Configuration drift | Multiple account/tenant IDs for the same provider can indicate fragmented identity management across business units. |
| Coverage gaps | Applications with no SSO record may be using local authentication outside centralized identity controls — see the Apps Without SSO card. |
| Insecure flows | Insecure/Weak security badges and Critical/High risk rows are the redirect and protocol weaknesses to fix first. |
| M&A / audit | The provider inventory is a continuously-updated authentication-mechanism inventory useful for SOC 2 / ISO 27001 / NIST 800-53 evidence and for due diligence. |
Key Metrics
The metrics strip shows six clickable cards. Clicking a card applies the corresponding filter (or, for the two cross-module cards, opens Web Applications).
| Card | Counts | Click behavior |
|---|---|---|
| SSO Providers | Distinct providers in the current scan | Opens the All tab |
| Needs Review | Providers awaiting triage | Filters to Needs Review |
| Unauthorized | Providers flagged unauthorized | Filters to Unauthorized |
| Insecure SSO | Records with security_status = insecure | Filters the list to insecure records |
| Apps Without SSO | Live apps minus apps with an SSO record | Opens Web Applications filtered to sso_providers = "none" |
| New This Week | Records first seen in the last 7 days | Opens All scoped to first_seen_on within the last 7 days |
Coverage math
Apps Without SSO = (distinct live web applications) − (distinct live applications with at least one SSO record). It is a coverage signal, not a defect list — many apps legitimately use local auth — but it's the fastest way to find applications outside your centralized identity perimeter.
Understanding the Data
Columns are configurable from the column customizer in the page header. Provider is always shown and cannot be hidden.
| Column | Description |
|---|---|
| Provider | Identity provider (e.g. Google, Azure AD, Okta, Auth0, OneLogin), with favicon. Sortable. |
| Account ID | The client ID, tenant ID, or configuration identifier embedded in the integration. Shown monospace. Sortable. |
| Application | URL of the web application the integration was found on. |
| Redirect URI | The OAuth/SAML redirect target. HTTP redirects are flagged with a warning icon. |
| Security | The goblin verdict (Insecure / Weak / Secure / Not Applicable / Not Assessed) with finding count. Sortable by underlying security severity. |
| Risk Level | Critical / High / Low, derived from the redirect URI (see How it works). Sortable. |
| Status | Review status: Needs Review, Approved, or Unauthorized. |
| Assigned To | Analyst the record is assigned to (off by default). |
| First Seen | When this configuration was first detected. Sortable. |
| Last Seen | When it was last observed in a scan. Sortable. |
Filtering & Search
Switch the status tabs (Needs Review / Approved / Unauthorized / All) for the primary triage cut — tab selection injects a review_status rule into the active filter set, so it composes with everything else you apply.
The filter bar supports these fields:
| Filter | Notes |
|---|---|
| Provider | The SSO provider name |
| Account ID | Client/tenant/config identifier |
| Review Status | Needs Review / Approved / Unauthorized |
| Application | The host/app the integration lives on |
| Redirect URI | Match on the redirect target |
| Security Severity | The goblin per-finding severity |
| Security Status | Insecure / Weak / Secure / Not Assessed / Not Applicable |
| Risk Level | Critical / High / Low |
| Assigned To | The analyst the record is assigned to |
| Bookmarked | Your bookmarked records |
| First Seen / Last Seen | Date-range filters |
The Bookmarked quick toggle (star) in the filter bar restricts the list to records you've bookmarked. Custom tags can be added as filter values where configured.
Detail View
Detail drawer
Click any row to open a side drawer for fast triage without losing your place. It shows the provider identity and review status, the account ID, the application (as a clickable link), the redirect URI (with an HTTP warning), risk level, the security verdict (and an MFA detected chip when applicable), and the full list of security findings with per-finding severity, title, and detail. From the drawer you can Approve, Flag Unauthorized, or Reset to review, and step through records with the prev/next arrows. Open full page jumps to the provider detail view.
Provider detail page
Opening the full page for a provider gives a summary strip — total Account IDs, total Applications, total Redirect URIs (with an HTTP count warning), and First Detected — plus four tabs:
- Account IDs — every account/tenant/config ID for this provider, with app count and first/last seen. Clicking a row opens Web Applications filtered to that provider and that specific account.
- Applications — the web applications using this provider, with URL, account ID, and last-scanned date. Clicking opens the application in Web Applications.
- Redirect URIs — each redirect target with a secure/insecure indicator, protocol (HTTPS/HTTP), and whether it contains a wildcard.
- Activity — a timeline of first detection, last scan, and any analyst status change.
Taking Action
| Action | Where | Effect |
|---|---|---|
| Approve | Row drawer, provider page, bulk bar | Marks the provider as a known, authorized integration |
| Flag Unauthorized | Row drawer, provider page, bulk bar | Marks the provider as rogue/unsanctioned for follow-up |
| Reset to Review | Drawer, bulk bar | Returns the provider to Needs Review |
| Assign | Bulk bar | Assign selected records to an analyst (or clear the assignee) |
| Bookmark | Row action, bulk bar, keyboard s | Save for later; filter with the Bookmarked toggle |
| Comment | Row action | Threaded comments, with comment templates |
| Share | Row action, bulk bar, provider page | Open the integration share modal (row/bulk) or copy a link to the provider page |
| Export | Filter bar | Exports the current filtered, sorted view |
Select rows with the checkboxes (or the header select-all) to reveal the bulk action bar: bulk Approve, Flag, Reset, Assign, Bookmark, and Share across every selected record at once.
Triage workflow
Work the Needs Review tab top-down. Approve providers your identity team recognises, Flag Unauthorized anything they don't, and use Insecure SSO / Critical risk filters to fast-track the configurations that are exploitable today. Approving in bulk by provider clears the backlog quickly because status is provider-scoped.
Keyboard shortcuts
j / k move to the next/previous record (opening the drawer), Enter opens the focused record, Space toggles selection, s bookmarks, and Esc closes the drawer.
Common questions
Is this the list of my logins, or logins on my applications? It's the SSO integrations configured on your web applications — the identity providers your apps delegate authentication to. It is not a list of your employees' accounts.
Why does one provider appear on many rows? Each row is a distinct detection (a sso_login_pages record): the same provider can be wired into many applications, use several account/tenant IDs, or declare multiple redirect URIs. The provider detail page consolidates them.
Why is the count different from what I see in the table? KPI cards and tab badges generally count distinct providers, while the All tab and filters count individual detection rows. Everything is also scoped to your most recent scan and to live (non-closed) applications.
What's the difference between Risk Level and Security? Risk Level is a quick structural read of the redirect URI alone (HTTP = critical, wildcard = high). Security is the deeper analyzer verdict covering protocol-level weaknesses (implicit flow, missing PKCE/state, weak SAML, etc.) with individual findings.
Why is a provider "Not Assessed"? The security analyzer hasn't evaluated that configuration yet (or the schema/assessment hasn't run for it). The record is still inventoried; it just lacks a security verdict for now.
Does Approve/Flag change anything in my identity provider? No. It's an internal triage label in ShadowMap. Use it to track which detected integrations you've vetted and which need investigation or takedown — remediation happens in your IdP.
How do I find apps that aren't using SSO at all? Click the Apps Without SSO card; it opens Web Applications filtered to applications with no detected SSO provider.
Related
- Web Applications — the source of SSO detections; drill-downs from this page land here, pre-filtered by provider/account.
- Technology Stack — the broader set of technologies and integrations fingerprinted on your applications.
- JS Trackers — another class of third-party integrations embedded in your web properties.
- SSL Certificates — certificate posture for the same applications hosting these login endpoints.
- Members — manage analyst accounts and roles for assigning and triaging SSO records.