OneLogin

Proofroom reads OneLogin’s API with an API credential and files four kinds of evidence. Add it on Integrations → Catalogue → OneLogin → Connect.

What each collector shows

Collector	Kind	Default cadence	What it shows	Suggested controls
Users with MFA status	snapshot	quarterly	Every user, with their OneLogin status (active, locked, password expired, suspended, unactivated, password pending and so on), and their registered MFA devices. The summary counts users per status. A user with no device listed reads as MFA unknown, not as without MFA (see below).	PCI DSS 8.4.2, 8.4.3; SOC 2 CC6.1
Admin and privileged roles	snapshot	quarterly	Every user holding a OneLogin privilege, and whether their account is active.	PCI DSS 7.2.1, 7.2.2, 7.2.4; SOC 2 CC6.2, CC6.3
Leaver removals	window	quarterly	Users deactivated, suspended or deleted in the window, with who did it. With a People directory source, each leaver’s removal is measured against their leave date (leaver lag).	PCI DSS 8.2.5; SOC 2 CC6.2
Inactive accounts	snapshot	quarterly	Every user OneLogin holds, with their status, creation date and last sign-in, and those with no sign-in for more than 90 days.	PCI DSS 8.2.6; SOC 2 CC6.2

Users with MFA status and Leaver removals are automatic only: the manual route offers the privileged users report.

Create the API credential

In the OneLogin admin portal, go to Developers → API Credentials → New Credential, name it “Proofroom”, and choose a scope:

Read Users covers admin roles, leavers and inactive accounts.
Manage users is needed for Users with MFA status: OneLogin offers users’ MFA devices only to that scope. Proofroom only reads with it; if you would rather not grant it, leave Users with MFA status off and use Read Users.

Copy the client ID and client secret. Proofroom never writes to OneLogin.

Connect

Field	Value
OneLogin address	Your account’s address, such as `https://example.onelogin.com`
Client ID, client secret	From the credential

Test connection calls users, event types and, for the first user, MFA devices, and says when the Manage users scope is missing.

Known limits

Users and privileges are read one user at a time, within OneLogin’s 5,000 calls an hour.
MFA evidence lists every user OneLogin holds, suspended ones included, each labelled with its status, because a locked, expired or suspended account can sign in again once unlocked, reset or unsuspended. Only deleted users, which OneLogin no longer returns, are left out. Admin-role evidence shows a suspended (status 2) holder as disabled.
OneLogin’s MFA devices API “only returns factors that are enrolled and can be verified via API”. A user with no device listed may still have another factor (for example a security key), so they read as unknown, not as without MFA; check those users in OneLogin. OneLogin documents no API that lists every enrolled factor. OneLogin’s v1 API offers the same list (/api/1/users/{id}/otp_devices) to a Read Users credential; whether it accepts Proofroom’s token is UNVERIFIED, so Proofroom uses the v2 call for now.
Leaver removals counts only OneLogin’s DEACTIVATED_USER, SUSPENDED_USER, SUSPENDED_USER_VIA_API and DELETED_USER events, found by name in OneLogin’s event types list at each run. Removals made only in an app or in a connected directory, and MFA device removals, are not counted. Events name people by display name, so Proofroom looks each one up by ID in the users list for their email; a deleted user is no longer listed and keeps the name OneLogin recorded.
Inactive accounts reads last_login and created_at from the users list; an empty last_login means the user has never signed in (OneLogin’s example shows this; its reference does not say it in words). Administrator status is not read there.

Credential expiry

OneLogin API credentials do not expire, and OneLogin offers no API that reads when one was made, so Proofroom shows no expiry for this integration. A credential stops working when it is deleted or disabled, or when the user who made it is deleted.