canonical: https://jentic.com/apis/developers.onelogin.com/onelogin

# OneLogin API

Jentic publishes the only available OpenAPI specification for OneLogin API, keeping it validated and agent-ready. OneLogin (now part of One Identity) is an enterprise SSO and identity provider used by mid-market and large organisations to centralise user authentication and SaaS app provisioning. This curated spec covers the API v2 endpoints that anchor most administrative integrations: minting an OAuth access token, listing users, and listing connected applications on the tenant.

## For AI agents

List OneLogin users and connected apps and mint OAuth access tokens for SSO administration and identity reporting.

## Scope

Does not handle SAML or OIDC SSO login flows, MFA enrolment, or end-user role management - use for OneLogin admin token mint, user listing, and app listing only.

## Capabilities

- Generate OAuth access tokens for the OneLogin API via POST `/auth/token` using client_credentials
- List directory users on a OneLogin tenant through GET /users for audit, sync, and reporting
- List connected SaaS applications via GET /apps to inventory the SSO surface
- Target any OneLogin tenant by templating the {subdomain} server variable for multi-tenant tooling
- Authenticate downstream calls with the bearer token returned by `/auth/token`
- Anchor identity-and-access workflows in front of provisioning and HRIS pipelines

## Use cases

### Quarterly user access review export

Compliance teams running SOC2 or ISO27001 access reviews use GET /users to export the OneLogin directory snapshot for review by application owners. The job mints a token via POST `/auth/token`, pages through users, and writes the result to a Google Sheet or BI tool for sign-off. Pairing with GET /apps gives the full who-can-access-what picture.

Example prompt: POST to `/auth/token` with client_credentials grant, then call GET /users with the returned bearer token and write the user list to a CSV file.

### SSO app inventory and rationalisation

IT teams use GET /apps to inventory every SaaS application connected to OneLogin so they can rationalise the SaaS estate, find shadow apps still wired to SSO, and map app ownership. The output feeds vendor risk reviews and budget conversations. The endpoint returns active and inactive apps so it doubles as a deactivation audit.

Example prompt: After token mint, call GET /apps and produce a markdown table of app name, connector, and active state for the IT review.

### Token automation for OneLogin admin scripts

Platform engineering teams running OneLogin admin scripts on schedule (Lambdas, GitHub Actions, internal cron) call POST `/auth/token` at the start of each run to mint a short-lived bearer token. This avoids storing long-lived credentials in CI secrets and keeps every access scoped to a single run. Tokens default to a one-hour TTL.

Example prompt: Call POST `/auth/token` with grant_type='client_credentials', store the returned access_token in memory for the run, and use it for subsequent /users and /apps calls.

### Agent-driven OneLogin queries via Jentic

AI agents handling IT support or compliance queries (e.g. 'how many users do we have in OneLogin?') can call OneLogin through Jentic without holding the OAuth client_id and client_secret. Jentic stores the credentials in your Jentic One instance, mints a token per call, and exposes high-level intents like 'list OneLogin users' so the agent stays in plain language.

Example prompt: Search Jentic for 'list OneLogin users', load the schema for GET /users, and execute against the configured tenant subdomain - Jentic handles the token mint.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/auth/token` | Generate an OAuth access token |
| GET | `/users` | List directory users |
| GET | `/apps` | List connected applications |

## Key resources

- **Auth Tokens** — Mint OAuth access tokens with the client_credentials grant
- **Users** — List directory users on the OneLogin tenant
- **Apps** — List connected SaaS applications

## Why Jentic

- **Setup:** Wiring the OneLogin API by hand means minting a fresh bearer token from your client_id and client_secret, filling in your account subdomain host, and refreshing that token yourself. Through Jentic you install once, import the OneLogin API from the API Directory, store the client credentials once, and your agent calls it.
- **Permission scoping:** You choose which OneLogin operations the agent may call, so you can limit it to the ones it needs, such as listing users and listing connected apps, and leave the token mint out of the agent's own reach unless you add it. That keeps the agent to admin reads without touching login or MFA flows.
- **Credential handling:** Your OneLogin client_id and client_secret are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list OneLogin users' or 'list connected apps', and Jentic returns the matching OneLogin operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Auth0** — Auth0 is the developer-first IDP alternative with broad social and enterprise connections
- **Okta** — Okta is the dominant workforce IDP with the largest SaaS app catalog and provisioning network
- **JumpCloud** — JumpCloud combines IDP, MDM, and directory in one platform as an SMB-friendly alternative

## FAQ

### Why is there no official OpenAPI spec for OneLogin API?

OneLogin publishes API documentation but not a single canonical OpenAPI specification covering the v2 admin surface. Jentic generates and maintains this spec so that AI agents and developers can call OneLogin API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the OneLogin API use?

OneLogin uses HTTP bearer authentication. Mint a token by calling POST `/auth/token` with grant_type=client_credentials and the client_id and client_secret as basic auth, then pass the returned access_token as 'Authorization: Bearer <token>' on subsequent calls. Jentic handles the mint and refresh transparently.

### Can I list all my OneLogin users with this API?

Yes. GET /users returns the directory of users on your tenant. The API is paginated; iterate through the cursor in the response to retrieve every record. Use this for access reviews and HRIS sync.

### What are the rate limits for the OneLogin API?

OneLogin enforces a per-tenant rate limit that is not declared in the OpenAPI spec. Standard tenants typically allow several thousand requests per hour with stricter limits on `/auth/token.` Build with retry-on-429 and confirm the live limit in the OneLogin admin console.

### How do I list OneLogin users through Jentic?

Run pip install jentic, then with the async client search for 'list OneLogin users', load the schema for GET /users, and execute. Jentic mints the bearer token automatically using the stored client credentials.

### Does this OneLogin spec cover SSO login flows?

No. The spec covers the admin v2 surface (token mint, users, apps). SAML and OIDC SSO login flows are exposed through separate OneLogin endpoints not included in this spec.

### Can I limit what my agent is allowed to do with the OneLogin API?

Yes. Because Jentic One is self-hosted, you decide which OneLogin operations your agent may call and your own rules govern the credentials it can use. You can allow it just the admin reads it needs, such as listing directory users via GET /users and listing connected apps via GET /apps, while leaving the OAuth token mint on POST `/auth/token` out of the agent's reach unless you choose to grant it. That keeps the agent scoped to identity reporting without touching login or MFA flows.