Oleria

C Oleria Adaptive Identity Governance (API)

The Oleria API only takes a one-hour JWT minted from a client ID and client secret created in the web app, with no federation, no expiry, no key-management API and no secret-scanning partnership. Into your stack it is keyless for AWS, Entra/M365, Google Workspace, GitHub and Salesforce, but GCP, Azure, Okta and Slack still want a pasted key, secret or token.

Docs: docs.oleria.com · Checked 2026-10-13 · source YAML · dispute via PR

Inbound C

How a workload running anywhere authenticates to this product.

OAuth 2.0 client credentials: a static client_id and client_secret created under Settings -> Manage API Keys are exchanged for a JWT access token that typically lives one hour.

docs.oleria.com checked 2026-10-13
“The Oleria API uses the OAuth 2.0 Client Credentials grant: you exchange a client_id and client_secret for a short-lived JWT access token, then pass that token as a Bearer credential on every API call.”
docs.oleria.com checked 2026-10-13
“Lifetime of the token in seconds (typically 3600, i.e. one hour).”
docs.oleria.com checked 2026-10-13
“Generate OAuth client credentials from the Oleria web app. The client secret is shown once, on the create (or rotate) success screen.”
docs.oleria.com checked 2026-10-13
“Programmatic access to your Oleria workspace, secured with OAuth 2.0 Client Credentials.”

No workload identity federation, OIDC token exchange, private_key_jwt or mTLS option is documented; the token request body must carry the client_secret. The API went GA in August 2026, so this may move. The Oleria MCP server uses interactive user sign-in, not a machine credential. On-prem agents (Active Directory, Ping Directory, PingFederate) dial out to api.<tenant>.oleria.io and auth.prod.oleria.io after being installed from a PowerShell script that Oleria generates. The docs do not say what credential the agent uses to authenticate back to Oleria (probably something embedded in that script). The AD agent also stores a customer AD service-account username and password.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Keyless for AWS (CloudFormation-created cross-account oleriaConnectorRole), Entra ID / M365 (admin consent to Oleria's app), Google Workspace (domain-wide delegation to Oleria's client ID), GitHub (Oleria Connector GitHub App) and Salesforce (Oleria's connected app). GCP wants a service-account JSON key, Azure RBAC a client secret or certificate, Okta a private key for a customer-created service app, and Slack bot and user tokens from a customer-created app.

docs.oleria.com checked 2026-10-13
“Return to your Oleria workspace and paste the Role ARN you copied. Select Confirm that the role is created using CloudFormation successfully, then select Authenticate.”
docs.oleria.com checked 2026-10-13
“Connect with Microsoft OAuth - automated configuration. Oleria creates the app and requests consent for you.”
docs.oleria.com checked 2026-10-13
“Grant domain-wide delegation so Oleria can discover Google Admin users and groups and Google Drive sharing.”
docs.oleria.com checked 2026-10-13
“You install the Oleria Connector GitHub App in your organization, then connect it from your Oleria workspace.”
docs.oleria.com checked 2026-10-13
“Oleria connects through an Oleria connected app that you install and assign to a dedicated permission set.”
docs.oleria.com checked 2026-10-13
“Service Account Credentials - paste the full contents of the JSON key file downloaded above”
docs.oleria.com checked 2026-10-13
“Azure authentication uses a Microsoft Entra ID service principal, either a client secret or a client certificate.”
docs.oleria.com checked 2026-10-13
“Save the key in PEM format and select Copy to clipboard. You will need this private key when connecting in Oleria.”
docs.oleria.com checked 2026-10-13
“Oleria connects using tokens issued from a Slack app that you create and install in your workspace or organization.”

Connectors checked: AWS, GCP, Azure, Entra ID / M365, Google Workspace, Okta, GitHub, Salesforce, Slack and Active Directory. Keyless: AWS, Entra (the Microsoft OAuth path; the client-secret and certificate paths are optional alternatives), Google Workspace, GitHub and Salesforce. Static keys: GCP (a service-account JSON key, even though the docs say Google blocks key creation by default on newer organizations), Azure RBAC (client secret or certificate on a customer app registration), Okta (private_key_jwt with a private key the customer generates and pastes in, so not an OIN app), Slack (xoxb bot and user tokens from a customer-created app) and Active Directory (a service-account password given to the on-prem agent). The AWS docs never mention an External ID, so the role's trust policy may not guard against the confused-deputy problem. It still counts as keyless. The more than 150 other SaaS connectors were not assessed one by one.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Creating a key asks only for a name. No expiry field, default lifetime or org policy for the client secret is documented. docs.oleria.com checked 2026-10-13 “Select Create API Key. Enter a descriptive name for your integration (for example, BI nightly export or internal access-graph viewer) and select Create.”
✗ Rotation via API	Creating, rotating and deleting keys is documented only in the web app. The API reference has no endpoints for managing API keys or clients. docs.oleria.com checked 2026-10-13 “Go to Settings -> Manage API Keys and open the key you want to rotate.”
✗ Scoped keys	The API defines separate read and write OAuth scopes, but the key-creation flow does not let the customer choose them. Changing a credential's permissions goes through Customer Success. Scored as a fail because the customer cannot scope the key themselves. docs.oleria.com checked 2026-10-13 “Contact Customer Success to confirm the credential has the right permissions.” docs.oleria.com checked 2026-10-13 “Requires the https://devx.{environment}.oleria.io/write scope.”
✗ Last-used visible	The key details panel lists the API URL, Authentication URL, Audience and Client ID. A last-used timestamp is not documented anywhere. docs.oleria.com checked 2026-10-13 “Open the new key from the list. The details panel shows the values you need besides the secret:”
✗ Leak revocation	Oleria does not appear anywhere on GitHub's supported secret scanning patterns list. docs.github.com checked 2026-10-13 “Partner alerts: Reported directly to secret providers that are part of secret scanning's partner program.”

Notes

Oleria's docs (docs.oleria.com) are public, and the API reference and OpenAPI fragments can be read without logging in. Graded on the public REST API at devx.<tenant>.oleria.io, which went GA in August 2026. Oleria's webhooks sign payloads with a shared secret and allow overlap during rotation. That covers outbound event delivery and does not change either grade. Inbound would move to A/B only if Oleria accepted federated workload tokens. Outbound would reach A if GCP moved to impersonation/WIF, Azure to a federated credential or multi-tenant consent, Okta to an OIN service app, and Slack to a Slack app owned by Oleria.

Badge

[![wif.tax grade](https://wif.tax/badge/oleria-identity-governance.svg)](https://wif.tax/p/oleria-identity-governance/)