Skip to main content
Connect OneLogin to Oleria to gain continuous visibility into who has access to what across your OneLogin tenant. Oleria reads identity, membership, and access data from the OneLogin API - mapping every user, group, role, and application in one place - so you can see where access is over-provisioned and take action directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your OneLogin tenant:
  • Users - every user in your OneLogin directory, with their status, last login, last password change, the MFA requirement from their security policy, and whether they sign in through a trusted IdP. With a Manage All credential, Oleria also reads each user’s enrolled MFA factors. Users who administer a role or hold a OneLogin admin privilege are flagged as administrators.
  • Non-human identities - the API credential this integration uses, with its client secret, and, with a Manage All credential, the OIDC client apps registered on your API Authorization servers, with their scopes.
  • Groups - every OneLogin group, each user’s group membership, and the group’s administrators.
  • Roles - OneLogin roles, with each user’s role assignments. With a Manage All credential and Delegated Administration, Oleria also reads custom privileges, the users they are assigned to, and the roles that grant them.
  • Applications - every application configured in OneLogin, and the users who can reach each one through their roles.
  • Impersonation - the users who can assume other users (the Assume users or Super user privilege).
  • Risks - when Vigilance AI scored sign-in attempts as high or very high risk in the last 30 days, Oleria raises a risk on your OneLogin tenant with the count in each risk band.
  • Activity - OneLogin events, such as sign-ins, app sign-ins, user changes, role and privilege changes, and MFA device changes. Oleria also backfills past events within OneLogin’s retention.
Groups in OneLogin are flat and single-valued - a user belongs to at most one group at a time, and groups do not nest or grant application or role access. See Known limitations.

​
Prerequisites

  • A OneLogin account owner or administrator who can open Developers -> API Credentials.
  • Your OneLogin subdomain - the part of your OneLogin URL before .onelogin.com (for example, acme if you access OneLogin at acme.onelogin.com).
Create a dedicated API credential pair for this integration rather than reusing an administrator’s personal credentials, to ensure continuity if that administrator leaves or changes roles.

​
Create an API credential pair in OneLogin

1

Open API Credentials

Sign in to OneLogin Administration and navigate to Developers -> API Credentials.
2

Create a new credential

Select New Credential and give it a descriptive name, such as “Oleria Integration”. Choose the scope:
OneLogin’s narrower scopes (Read Users, Manage users) are not enough for discovery: applications and security policies need Read All. Oleria checks this when you connect.
3

Copy the credentials

Save the credential, then copy the Client ID and Client Secret.
Store the Client Secret securely, as you would a password.

​
Connect OneLogin to Oleria

1

Open the integration

Sign in to your Oleria workspace, navigate to Integrations, and select OneLogin.
2

Complete the connection form

Fill in the connection form with the credentials from the API credential pair:
3

Authenticate

Select Authenticate to validate and save the integration. Oleria checks the credentials against OneLogin before saving.

​
Verify the integration

Confirm the OneLogin instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered users, non-human identities, groups, roles, applications, and activity in your Oleria workspace.

​
Remediation actions

With a Manage All scoped credential, Oleria can take the following actions directly against OneLogin:
  • Disable, enable, or activate a user’s account. Activation applies to unactivated or suspended users. Locked users are unlocked in OneLogin instead.
  • Add or remove a user from a group.
  • Add or remove a role from a user.
  • Grant or revoke a user’s access to an application, by adding the user to the role that carries the application, or removing them from every role they hold that carries it.
  • Log a user out of OneLogin.
  • Create or delete a user, and create a group.
A Read All credential connects and syncs successfully, but remediation actions fail. OneLogin has no API that reports a credential’s scope. Oleria checks ahead of time before creating users or groups. Other actions fail when Oleria applies them.

​
Known limitations

  • Application access is role-mediated. OneLogin has no API to assign or revoke a specific user’s access to a specific application directly - access is granted through the roles a user holds. Granting access works only when exactly one role carries the application. Otherwise, add the user to the intended role. Revoking access removes the user from every role that carries the application, which also removes any other applications those roles grant.
  • Groups do not grant application or role access. OneLogin groups are membership-only, with no group-to-role or group-to-application assignment. A user’s application and role access comes entirely from their role assignments, not their group.
  • Group membership is single-valued. A OneLogin user belongs to at most one group at a time; Oleria reflects this one-to-one relationship rather than a many-to-many membership model.
  • Impersonation is reported tenant-wide. OneLogin lets an Assume users holder assume any unprivileged user. It doesn’t list the users each holder can assume, so Oleria shows the holder as able to assume every user in the tenant.
  • Only this integration’s API credential is discovered. OneLogin doesn’t offer an API to list API credentials, so other credential pairs aren’t tracked as non-human identities, and no API can disable one.
  • Custom privileges need Manage All and Delegated Administration. OneLogin serves its privileges API only to a Manage All credential on a subscription that includes Delegated Administration. Without either, Oleria syncs roles without privileges.
  • MFA factors need Manage All. OneLogin returns users’ enrolled MFA factors only to a credential with a Manage scope. With Read All, Oleria shows whether each user’s security policy requires MFA, but not which factors they enrolled.
  • Risk is reported for the tenant, not per user. Vigilance AI shares only how many sign-in attempts fell into each risk band over the last 30 days, so Oleria’s risk is raised on the OneLogin tenant. The risk score of each sign-in is kept on its activity event. Vigilance AI must be enabled on your OneLogin account.
  • Large tenants take longer to sync. OneLogin has no bulk API for MFA factors or admin privileges, so Oleria reads them one user at a time, within OneLogin’s limit of 5,000 API calls per hour for your account.

​
Contact us

For questions about this integration, contact us at support@oleria.com.