Skip to main content
Descope is a customer identity (CIAM) platform. Connect a Descope project to Oleria to see who can sign in to the project, what tenants and roles they hold, and who can administer Descope itself. Oleria reads this data from the Descope Management API with a management key. You can then review over-provisioned access and take action directly from Oleria. One Oleria integration covers one Descope project. To connect another project, such as a staging project next to production, add another integration.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Descope project:
  • Users - the project’s users, with name, email, login ID, and status. Users that are enabled or invited are shown as enabled, because invited users can already sign in. Users that are disabled, or whose invitation expired, are shown as disabled. Oleria also shows each user’s last sign-in, enrolled authentication methods, and MFA and SSO status. Users that hold one of Descope’s system permissions (Super User, User Admin, SSO Admin, or Impersonate) are marked as administrators. Descope test users aren’t synced.
  • Groups - two kinds:
    • Tenants - each tenant is shown as a group. Its members are the users and access keys that belong to the tenant.
    • SCIM and SSO groups - the groups inside each tenant that were provisioned through SCIM or created at SSO sign-in, with their members.
  • Roles - the project’s roles and tenant roles, and who holds them. A project role granted inside a tenant is shown as a separate tenant-scoped role named <role> @ <tenant>, so each grant can be reviewed and removed on its own. Roles that a tenant’s SSO configuration maps to SCIM or SSO groups are shown as roles of those groups.
  • Applications - federated applications, the OIDC and SAML applications Descope signs users in to. Users get access directly or through a tenant the application is assigned to.
  • Console administrators - the Descopers who can sign in to your Descope Console, with the console roles that cover this project. Company admins are marked as super administrators. Descopers whose roles don’t cover this project are still shown, without a role.
  • Non-human identities (NHIs):
    • Access keys - the project’s machine-to-machine keys, shown as API tokens. A key bound to a user is shown as a personal access token, linked to the user it acts as. SCIM provisioning keys are included.
    • Management keys - your company’s management keys, shown as API tokens, with the management key roles that apply to this project.
    • Inbound apps - third-party OAuth applications, shown as applications. Oleria shows which users consented to each app, and the scopes they granted.
    • Descope (system) - one account that stands for Descope itself. Oleria uses it as the actor for events that Descope writes on its own.
    Keys show their status (active, disabled, or expired), creation and expiry dates, roles, and creator when Descope records it. Their last-used date comes from the audit log.
  • Activity - events from the Descope audit trail, such as:
    • sign-ins and failed sign-ins, including Descope Console sign-ins and impersonation
    • user creation, changes, deletion, and disabling or enabling
    • role, permission, and tenant changes
    • password and SSO enforcement changes
    • access key and management key creation, changes, and deletion
    • inbound app consents granted and revoked
    Events Oleria doesn’t recognize are kept as custom events.

​
Prerequisites

  • A Descope project, on any plan.
  • A Descope Console account that can create management keys in your company, such as a Company Admin.
  • Admin access on the Oleria platform to add a new integration.

​
Permissions

Oleria uses one management key for both discovery and remediation actions. The key’s roles decide what Oleria can read and change: The project roles also work as company-level roles (for example, company-asset-mgmt-read) or tag-level roles. A Full Access role covers all of them. If the key can’t read Descopers or management keys, Oleria still syncs the rest of the project. If the key can’t read SCIM and SSO groups, tenant SSO settings, federated applications, or inbound apps, Oleria skips them and syncs the rest of the project. If one of these is missing after the first sync, grant the key Full Access for the project or contact support.
Descopers - Read & Write and Management Keys - Read & Write have no read-only variants and apply to your whole Descope company. A key with them can change console administrators and every management key in the company, in every project. Grant them only if you want Oleria to inventory console administrators and management keys, or to disable management keys. Store and rotate this key as you would a company admin credential.
Use a dedicated management key for this integration. Oleria never disables the management key it connects with.

​
Create a management key in Descope

1

Copy the Project ID

In the Descope Console, select the project you want to connect, go to Project Settings -> General, and copy the project ID.
2

Create the management key

Go to Company -> Management Keys and create a key. Name it Oleria, and choose an expiration that fits your policy: 30, 60, or 90 days, or never. Associate the key with the project you want to connect, or leave it company-wide. Descope sets this association when you create the key, and you can’t change it later.
3

Grant the roles

Grant the project roles listed in Permissions for the project. If you want Oleria to inventory console administrators and management keys, also grant the company roles Descopers - Read & Write and Management Keys - Read & Write. Read the warning about these roles first.
4

Set permitted IPs (optional)

If you restrict the key to permitted IPs, add Oleria’s IP addresses. Contact support@oleria.com for the current list.
5

Copy the key

Copy the management key. Descope shows it only once.
The Descope Console changes over time. If these steps don’t match what you see, refer to Descope’s management keys documentation.

​
Connect Descope to Oleria

1

Open the integration

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

Complete the connection form

Fill in the connection form:
3

Authenticate

Select Authenticate. Oleria checks that the management key can reach the project and has Asset Management - Read Only and Infra Management - Read Only, or roles that include them, before it saves the integration. If a role is missing, Oleria names it. A missing Audit Handling role doesn’t block the connection. The integration is named after your Descope project.

​
Edit the connection

You can change the Management Key and Base URL of an existing integration. Leave Management Key blank to keep the stored key. You can’t change the Project ID. To connect a different project, add a new integration.

​
Verify the integration

Confirm the Descope integration appears on the Connected tab of your Oleria Integrations page. After the first sync completes, review the discovered users, tenants, groups, roles, federated applications, console administrators, NHIs, and activity in your Oleria workspace.
If you rotate the management key in Descope, the old key stops working immediately. Update the Management Key in Oleria by editing the integration. Discovery stops until you do.

​
Remediation actions

Oleria runs actions with the integration’s management key. Each action needs the roles listed below. Each action needs these management key roles: When the key has Management Keys - Read & Write, Oleria checks its roles before an action runs. Without it, Oleria can’t read the key’s roles, so an action without the write role fails when Oleria makes the change. Oleria refuses these actions and sends no change to Descope:
  • Disabling the management key the integration connects with. Oleria also refuses to disable any management key when it can’t identify that key, for example when the key lacks Management Keys - Read & Write.
  • Changing SCIM or SSO group membership or application assignments, or creating a user in one of these groups. These groups are managed by the tenant’s identity provider; change them there.
  • Changing Descopers, management keys, or inbound apps with user actions, and assigning console or management key roles to users.
  • Disabling inbound apps. Descope has no disabled state for them, only irreversible secret rotation, consent deletion, or app deletion.
  • Disabling the Descope (system) account.
Keep these points in mind:
  • If the target is already in the requested state, the action succeeds without making a change, and there’s nothing to revert.
  • Reverting checks the target first. If it changed after the action ran, or no longer exists, Oleria leaves it as is.

​
Known limitations

  • One project per integration. Descope keeps users, tenants, roles, keys, and audit events per project. Add one integration for each project you want to see.
  • Company-level data repeats per project. Descopers and management keys belong to your Descope company, so they appear in every Descope integration for that company.
  • Activity history depends on your plan. Descope keeps audit events for 1 week on the Free plan and 1 month on the Pro and Growth plans, and its API returns at most the last 30 days. The first sync imports activity from that window only. Last-used dates of keys and Descopers’ last sign-in come from the newest audit events Oleria reads on each sync. That covers up to the last 30 days, and less on busy projects, because Oleria reads at most about 10,000 of the newest events for these fields. A key or Descoper with no event in that range has no last-used date. The creator of a management key or inbound app is shown only when Oleria has seen its creation event.
  • Last password change comes from audit events. Descope doesn’t store a password-change date on the user. Oleria shows one only when a password was created or changed within that range.
  • MFA status comes from enrolled factors. Descope defines MFA in its flows, which its API doesn’t expose. A user with an enrolled authenticator app, passkey, or push factor is shown with MFA required. For other users, MFA status isn’t known, even if a flow asks them for a one-time code. MFA and SSO status aren’t known for Descopers.
  • SCIM and SSO groups are read-only. The tenant’s identity provider manages them, so Oleria has no actions for them.
  • Descopers are read-only. Descope’s API can’t disable a Descoper, so Oleria has no actions for them. Manage console administrators in the Descope Console.
  • Not synced yet. Tenant SSO identity provider configurations and outbound apps, which store third-party tokens for users, aren’t synced.

​
Contact us

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