What your identity provider shows you about access, and what it hides

why the picture is partial by design

Before the per-provider walkthroughs, it helps to name why the gap exists. Three things are going on at once.

First, access accumulates and rarely gets removed. Every new tool, integration, and contractor adds grants. Offboarding removes some of them. The net direction is upward. A console that is accurate today drifts out of date by default.

Second, access shows up in more than one place inside a single console. The sign-in record, the assigned applications, the OAuth consent grants, and the admin roles are four separate views of four different things. Reading one and assuming you have read access is a common mistake.

Third, the directory only knows about what authenticated through it. Federated sign-in, provisioning, and OAuth consent all leave a trace because they involve the provider. A standalone account created directly with a vendor does not. This is the structural limit, and it is the same across all three platforms.

The Verizon 2026 Data Breach Investigations Report found that a third party was involved in 40 percent of breaches. That number describes the wider pattern rather than your environment specifically. It is a reason to know what the third parties connected to your environment can actually reach, which is exactly what the OAuth grant inventory in your console is for, and exactly what the standalone-account gap hides.

google workspace

Google Workspace is, for this question, the most generous of the three. It keeps a usable inventory of the third-party applications that hold OAuth grants against your Workspace data, and it puts that inventory in the admin console where an admin can read it.

where to look

Everything here is in the Google Admin console at admin.google.com.

• Security, then API controls, then App access control. The centre of the third-party picture. It lists the apps that have been granted access to Google services through OAuth, shows the scopes each app holds, and lets you mark apps as trusted, limited, or blocked.
• Security, then API controls, then Manage Google Services. Controls which Google services are on for which organisational units.
• Directory, then Users. The account inventory. Who exists, who is suspended, who was created recently, and which accounts are not tied to a current employee.
• Account, then Admin roles. Who holds super admin and delegated admin roles.
• Reporting, then Audit and investigation. The activity record. Token grants, admin actions, and login events are queryable here.

what it shows well

The App access control view is the strength. It answers a question most consoles answer poorly: which outside applications currently hold access to our mail, files, calendar, and other Google data, and what can each one read or write. Because Google brokers OAuth consent for Workspace data, those grants land in one place. You can see the scope, see which users authorised the app, and restrict or revoke from the same screen.

what it does not surface

The view is bounded by Google's own services. A SaaS tool your team uses heavily, with its own login and no Google connection, does not appear here, because it never asked Google for anything. The console shows apps connected to Google. It does not show your application estate. It also does not narrow scopes for you or tell you whether a granted scope is actually used. The judgement about whether a grant is excessive is yours to make.

microsoft entra

Entra, the identity layer of Microsoft 365, is the other platform that keeps a real third-party grant inventory. The vocabulary is Microsoft's own, and the access lives across a few related views, but the substance is there.

where to look

Everything here is in the Microsoft Entra admin centre at entra.microsoft.com, or the equivalent panes in the Azure portal.

• Identity, then Applications, then Enterprise applications. The inventory of applications added to your tenant, including third-party SaaS apps that users or admins consented to. This is the equivalent of Google's connected apps view.
• Within an enterprise application, the Permissions view. Shows the delegated and application permissions the app holds, and whether they were granted by admin consent or user consent.
• Identity, then Applications, then App registrations. Applications registered in your tenant, typically your own or partner-built apps.
• Enterprise applications, then Consent and permissions. The settings that govern who can consent to what.
• Identity, then Monitoring, then Sign-in logs and Audit logs. The activity record.

what it shows well

Entra exposes the OAuth grants and consented applications in a tenant, with the admin-consent versus user-consent distinction made explicit. That distinction is the useful part. It lets you separate apps an administrator deliberately approved from apps individual users granted access to on their own, which is often where unreviewed access comes from. The Permissions view tells you the scope each app holds and how it got there.

what it does not surface

As with Google, the grant inventory only covers apps that integrated with Microsoft 365. A SaaS application your team logs into directly, with no Entra connection, is not an enterprise application and does not appear. The views are also more spread out than Google's. An admin who reads only the enterprise applications list without opening the permissions view sees that apps exist without seeing what they can do. The completeness is there. It takes more clicks to assemble.

okta

Okta is a dedicated identity provider, and it is very good at the job it was built for: authenticating people and assigning them to applications. The honest point about Okta in the context of this guide is about a thing it does not do, so it is worth being precise.

where to look

Everything here is in the Okta admin console.

• Applications, then Applications. The catalogue of applications integrated with Okta for sign-in, with the assignment model for each.
• Directory, then People and Directory, then Groups. The account and group inventory.
• Security, then Administrators. Who holds administrative roles in Okta itself.
• Reports, then System Log. The activity record. Authentications, assignments, admin actions, and policy changes are queryable here, and the System Log is genuinely detailed.

what it shows well

Okta gives you a clean view of the sign-in and assignment layer. Which applications are wired up for single sign-on, which users and groups are assigned to each, how assignment is driven by group membership, and a thorough activity log of authentication and administrative events. For answering who can sign into what through our identity provider, Okta is precise.

what it does not surface

Okta is an identity provider for sign-in and assignment. It does not maintain a third-party OAuth-app grant inventory the way Google Workspace and Entra do for their own data. Google and Entra each broker consent for access to their own platform's data, so the grants third-party apps hold against that data collect in one place. Okta sits in front of applications as the sign-in broker. It is not the data platform those third-party apps are reaching into, so there is no equivalent single screen that enumerates what standing data access every connected app holds. This follows from where Okta sits in the architecture rather than from any configuration gap on your side. If you run Okta in front of Google Workspace or Microsoft 365, those underlying platforms still hold their own grant inventories.

the comparison, side by side

• Google Workspace · What it shows well: Third-party OAuth grants against Workspace data in one place, with scopes, authorising users, and trust controls. Users, admin roles, and an audit log. · What it does not surface: Apps with no Google connection. Whether a granted scope is actually used. Your wider application estate.
• Microsoft Entra · What it shows well: OAuth grants and consented enterprise applications, with admin-consent versus user-consent made explicit. Per-app permissions, consent settings, sign-in and audit logs. · What it does not surface: Apps with no Microsoft 365 connection. A single assembled view (the data is spread across several panes).
• Okta · What it shows well: Sign-in and assignment: which apps are wired for SSO, who is assigned, group-driven assignment, and a detailed system log. · What it does not surface: A third-party OAuth-app grant inventory comparable to Google and Entra. What connected apps can read or write inside their own platforms.

One thing every row shares: none of these consoles sees an application that no one connected to the directory at all.

what none of them show

The strongest part of the per-provider picture, the OAuth grant inventory in Google and Entra, depends on the application having connected. The application asked for access to your data, the user or admin consented, and the grant was recorded. That connection is what makes the access visible. Two common kinds of access never make that connection, so they are invisible to all three providers.

The standalone account. A person signs up for a tool with their work email and a password they chose. There is no single sign-on, no OAuth consent, no provisioning. The tool may hold company data, may be paid for on someone's card, and may have been in use for years. From the directory's point of view it does not exist. This is the most common form of access that a clean read of the provider will still miss entirely.

The browser extension. An extension installed on an employee's browser runs on the endpoint with whatever permissions it requested at install. It can read page content, including content from your SaaS applications, and it answers to the extension's publisher, not to your directory. The identity provider has no visibility into it because the extension never authenticated through the directory. It lives on the device.

The shared logic is simple. The directory sees what connected to it. It does not see what bypassed it. A standalone signup and a browser extension both bypass it, by design. This is why even a careful, complete read of your provider is a partial map. It is an accurate map of everything that connected. It is silent on everything that did not.

the practical takeaway: read the provider properly, then close the gap

The conclusion is a sequence, not a tool choice.

First, read your provider properly. Most environments have not done this. The OAuth grant view in Google or the enterprise applications and permissions views in Entra usually contain grants nobody remembers approving, often consented by users rather than admins, sometimes held by tools the company stopped using. On Okta, the assignment and system log views are worth the same careful pass for who can sign into what. A thorough read of the console you already pay for is the highest-value step available, and it costs nothing but attention.

Then close the gap the console cannot see. Once you have read everything the directory knows, you still have the standalone accounts and the endpoint extensions it cannot know about. Two inputs close most of that gap without a new platform:

• Expense data. Card statements and accounts-payable records show recurring SaaS charges. A subscription on the company card that does not correspond to anything in your single sign-on or your OAuth grant inventory is a standalone account by definition.
• A short staff survey. Ask people what they actually use to do their work. The answers routinely include tools that never appear in any admin console, because individuals adopted them directly. It is the cheapest discovery method available for access that left no directory trace.

Combine the provider read with the expense reconciliation and the survey, and you have a far more honest application inventory than the directory alone produces. Even then the map has edges. Endpoint extensions need endpoint visibility to fully enumerate, and contractor-held accounts may sit outside both your directory and your expense system. The goal is to stop treating a clean directory read as the whole picture, because it is structurally only part of one.