Home > Identity and access > OAuth client lifecycle
OAuth client lifecycle
Last updated: 2026-11-03Cadence: Monthly
Subscription model: All
Roles: Tenant Admin (TA), Service Account Owner (SAO)
Last verified: 2026-05
| Initial | Recurring | |
|---|---|---|
| Estimated time | 1 hr | 30 min |
Benefits:
- Catches consent-method drift on published OAuth clients (Trusted reverts to Required when published)
- Confirms scopes are still narrowly granted to each client (avoid
admin_classic/offline_accesssprawl) - Surfaces orphaned bot users created by deleted M2M clients
- Validates that integrations are reaching the endpoints they need (failed scopes manifest as silent 401s)
Goal
Qlik Cloud has no native UI for OAuth-client expiry alerts or audit history. Admins must compensate via the Audits API and a documented monthly review. See the gotchas section below for the three behaviors that most often trip up new OAuth-client owners.
Permission model reminder. A bot user with TenantAdmin-equivalent tenant scope still can't read or write space-scoped content without an explicit space role on each target space—Qlik's three permission layers (entitlement, security role, space role) all apply independently. See Glossary → Identity, access, and security.
Tasks
| Task | TA | AA | DA | AuA | SAO |
|---|---|---|---|---|---|
| Inventory every tenant-level OAuth client and its associated bot user; confirm the bot user has the space roles each integration needs (see gotchas: bot users not implicit space members) | ✓ | ||||
| Confirm Trusted-consent M2M clients are still unpublished (see gotchas: publishing reverts consent to Required) | ✓ | ✓ | |||
Audit granted scopes per client; remove admin_classic / offline_access where they aren't actually required |
✓ | ✓ | |||
Cross-reference Audits API for oauth.client.*, api-key.*, and bot-user activity to catch creates / deletes that bypass the UI |
✓ | ||||
| Document the JIT provisioning path (Users API + Groups API) for any embedded app that uses M2M impersonation (see gotchas: M2M impersonation can't create users) | ✓ | ||||
| Remove orphaned bot user accounts when a tenant-level OAuth client is deleted—the bot user isn't auto-removed, and removal has no admin rollback once integrations have been re-pointed | ✓ | ✓ |
Read before acting—gotchas
- Trusted M2M clients only stay trusted while unpublished. Publishing the OAuth client silently reverts the consent method to Required, which breaks any flow that assumed Trusted. Keep production M2M clients unpublished and documented internally.
- OAuth M2M bot users aren't implicit space members. The bot user (created on first M2M token request) inherits
TenantAdmin-equivalent privileges, but a space still gates content access via space roles. Add the bot user as a space member where the integration must read or write, otherwise calls return empty data without an error. - M2M impersonation can't create users. Impersonation fails on first-time user IDs; embedded apps must call the Users API + Groups API in parallel to provision before the first impersonation attempt.
Automation helpers
- Alert API key owners about API key expiration within X days—Adjacent: surfaces approaching-expiry API keys; OAuth client secrets still need a parallel external tracker.
References
- OAuth overview (qlik.dev)
- Creating and managing OAuth clients (Qlik Help)
- Trusted vs Required consent (community)
- OAuth M2M bot user space-permission constraint (community)
- M2M impersonation can't provision users (community)
- Scope misconfiguration causing 401s (community)
Tags: #monthly #identity_and_access #oauth #m2m #bot_users #secrets