- Read-only means the tool can read sign-in and license-assignment data but cannot create users, reset passwords, or change your directory.
- Verify it by reading the exact OAuth scopes at connect time, not the marketing page: a read scope reads, a write or manage scope writes.
- Directory-wide read permissions still need admin consent, so loop in your identity admin early.
- Read-only analytics is not provisioning: if a tool requests write access, that is a separate, bigger decision.
Yes: a well-built SaaS management platform connects to Okta, Microsoft Entra, and Google Workspace with read-only access. It can read sign-in activity and app assignments, but it cannot create users, reset passwords, or change anything in your directory.
The way to confirm that is not to trust the vendor’s marketing page. It is to look at the exact permission scopes the tool asks for when you connect it. “Is it really read-only?” is one of the first questions a security reviewer asks, and for good reason: in most mid-market software purchases the security review, not the product demo, is the step that decides the deal. This guide explains what read-only means for each identity provider, what the integration reads and never touches, and how to verify the answer yourself.
Is a SaaS management tool really read-only when it connects to your identity provider?
It is read-only if, and only if, the scopes it requests are read scopes. A read-only integration retrieves data from your directory but cannot write back to it. It can pull who signed in to which app and when, and which users are assigned which licenses. It cannot add a user, remove a user, change a group, or touch a password.
What does “read-only” mean for Okta, Microsoft Entra, and Google Workspace?
Each identity provider expresses read-only the same way: a read permission has a “read” scope, and a write permission has a separate, clearly named “write” or “manage” scope. You grant one or the other, so a tool that only needs to read never has to hold a write permission.
- Microsoft EntraEntra uses OAuth 2.0 scopes through Microsoft Graph.
User.Read.Allreads user profiles andGroup.Read.Allreads groups, whileDirectory.ReadWrite.Allis a separate permission that writes. A read-only tool requests the.Readscopes and not the.ReadWriteone. Microsoft’s guidance is that apps should ask only for the permissions they need (Microsoft Learn: Scopes and permissions). - OktaOkta works the same way through scoped API access. A read integration uses scopes that read users and read system logs. Scopes that manage or modify users are separate and are not requested by a tool that only reads sign-in data. If the connection asks to manage users, that is write access, and it should be justified.
- Google WorkspaceGoogle’s Admin SDK marks read-only scopes with a
.readonlysuffix. A read-only tool requests those to read users and reports, not the read-write equivalents. Google also lets an admin classify a connected app with limited rather than trusted access, which keeps the app to unrestricted data only. Limited is the safer setting.
What data does the integration actually read, and what does it never touch?
A read-only SaaS management integration reads three things: sign-in events, app and license assignments, and basic directory attributes like name, email, and whether an account is active. It does not read passwords, multi-factor secrets, email, files, or message content, because those are not in the scopes it requests.
That narrow read is enough to answer the questions the tool exists to answer. Who is actually using this app? Which paid seats have not been signed into in 90 days? Which accounts are inactive and still hold licenses? None of that requires write access, and none of it requires reading the contents of anyone’s mailbox or drive. If you ever see a SaaS management tool asking for mail or file scopes to do license analytics, ask why.
How do you verify read-only during a security review?
You verify it by reading the requested scopes at connect time and confirming none of them can write. The marketing page is not evidence. The consent screen and the vendor’s scope documentation are. Run this short check:
- Read the actual scopesGet the real scope names the app requests, not a summary. On Entra and Google they appear on the consent screen; ask the vendor for the exact list in writing.
- Confirm nothing writesLook for
ReadWrite,manage, or any scope without a read-only marker. A read-only tool has none. - Check who consentsDirectory-wide read permissions are admin-restricted, so an administrator has to approve them on behalf of the organization. Loop your identity admin in early.
- Apply least privilegeThe default should be read-only, with write access added only when a feature genuinely needs it. Auth0 frames it well: limit the scope to read-only when write access is not needed (Auth0: Principle of Least Privilege).
- Confirm you can revokeMake sure you can disconnect the app from your identity provider at any time, and ask what happens to synced data and stored tokens when you do.
Read-only visibility versus provisioning: why the difference matters
Read-only visibility and provisioning are two different jobs, and they carry two different risk profiles. A read-only analytics tool watches usage; a provisioning tool creates and removes accounts. The second needs write access, and that is a bigger decision you should make on purpose. If you later want automated provisioning or deprovisioning, that is a separate capability with a wider blast radius, and your security team will want to review the write scopes on their own merits. Keeping the two decisions separate keeps each review clean.
Where read-only SSO data fits in a complete usage picture
Read-only SSO data is the foundation of app visibility, but it is not the whole picture, because single sign-on logs only see the apps that sit behind single sign-on. Plenty of software gets bought on a credit card and never touches your identity provider, which is where shadow IT hides.
In License Logic’s interviews with 80 mid-market executives, 49% said they lacked centralized visibility into their SaaS. Read-only SSO analytics closes part of that gap by showing real sign-in behavior across Okta, Entra, and Google. Spend data from finance systems and an optional macOS usage agent close the rest, so you can see the apps that never show up in an SSO log. Layering these read-only sources is how you move to centralized SaaS license visibility without ever granting write access to your directory.
License Logic connects to Okta, Microsoft Entra, and Google Workspace on a read-only basis to surface unused licenses and inactive users. It reads from your identity provider; it is not one. Encryption, data retention, deletion timelines, and the full subprocessor list are on the security page for your reviewer.
Frequently asked questions
Is it really read-only?
Yes, if the integration only requests read scopes. Read-only means the tool can retrieve sign-in and license-assignment data from Okta, Microsoft Entra, or Google Workspace, but it cannot create users, change groups, or reset passwords. Confirm it by reading the exact scopes on the consent screen rather than the marketing page. A read scope reads, and changing anything would require a separate write or manage scope.
Does connecting it change anything in my Okta, Entra, or Google directory?
No. A read-only connection cannot write to your directory, so it leaves users, groups, licenses, and settings exactly as they are. It only reads. If a tool asks for a write or manage permission, that is a separate grant your admin has to approve on purpose, and it should be justified before you approve it.
What permissions does the integration request?
It requests read scopes for sign-in activity, app and license assignments, and basic user attributes like name, email, and active status. On Microsoft Entra that looks like a read permission such as User.Read.All rather than the write permission Directory.ReadWrite.All. On Google Workspace it uses read-only Admin SDK scopes marked with a .readonly suffix. Ask the vendor for the exact list in writing.
Do you need a super-admin or global-admin account to connect it?
You need an administrator to consent, because directory-wide read permissions are admin-restricted and a regular user cannot approve them. That is a one-time consent step, not a grant of ongoing admin power to the tool: the tool still only holds the read scopes it requested. Involve your identity admin early so the review does not stall on the consent screen.
Can I revoke access later, and what happens to synced data?
Yes. You can disconnect the app from your identity provider at any time, which invalidates its access and stops any further reads. Ask the vendor what happens next: a straight answer covers whether stored tokens are deleted, how long already-synced analytics are retained, and how to request full deletion. Get that in writing during the review.