Okta
Identity & SSOsystem_type: "okta"Proxy Okta Management API calls with PQC-sealed OAuth2 client credentials and signed audit events.
Overview#
The Okta connector proxies calls to the Okta Management API v1 (users, groups, applications, factors, logs). OAuth2 client credentials or API tokens are sealed in QuantaVault. Every proxied call is logged to the QuantaSeal immutable audit hash chain.
https://api.quantaseal.io/api/v2/proxy/outboundAuth header:
X-API-Key: qs_live_...Prerequisites#
- 1An Okta organization with API Access Management enabled
- 2An Okta OAuth2 service application or an API token with admin scope
- 3Your Okta domain (e.g. https://yourorg.okta.com)
- 4A QuantaSeal API key
Configuration#
Follow these steps to connect Okta to QuantaSeal. You can configure integrations via the Admin Console or directly via the API.
- 1
In Okta Admin Console, create a Service App (Applications → Create App Integration → API Services). Note the Client ID and Client Secret.
- 2
Grant the app an OAuth2 scope for the Management API (okta.users.read, okta.groups.manage, etc.).
- 3
Seal credentials: POST /api/v2/vault/seal with credential_type: oauth2_client.
- 4
Create the integration: POST /api/v2/integrations with system_type: okta and your Okta domain.
Authentication Types#
Prefer oauth2_client (Okta OAuth2 service app with client_credentials) over static API tokens in production. API tokens use the api_key credential type.
All credential types are sealed in QuantaVault with ML-KEM-768 + AES-256-GCM and wrapped by your tenant AWS KMS CMK before storage. See the Vault API reference for the full list of credential types and seal/unseal endpoints.
Available Operations#
QuantaSeal enforces a default-deny operation policy. Only operations listed in your integration's allowed_operations array will be permitted. Add operations when creating or updating the integration.
| Operation | Description |
|---|---|
list_users | List users with optional search/filter. |
get_user | Retrieve a user profile by ID or login. |
create_user | Create a new user. |
deactivate_user | Deactivate (suspend) a user. |
list_groups | List groups with optional search. |
list_applications | List assigned applications. |
get_system_log | Retrieve Okta system log events. |
Code Example#
Every proxy call returns a HybridCryptoEnvelope - the response is ML-KEM-768 key-encapsulated, AES-256-GCM encrypted, and signed with ML-DSA-65 + HMAC-SHA-512. Verify both signatures before trusting the decrypted payload.
curl -X POST https://api.quantaseal.io/api/v2/proxy/outbound \
-H "X-API-Key: qs_live_your_key_here" \
-H "Content-Type: application/json" \
-d '{
"integration_id": "int_01HZ9X2K4MNPQROKTA000001",
"operation": "list_users",
"payload": {
"filter": "status eq \"ACTIVE\"",
"limit": 25,
"search": "profile.department eq \"Engineering\""
}
}'
# Response - HybridCryptoEnvelope
{
"success": true,
"encrypted": {
"ciphertext_kem": "<base64 - 1088 bytes ML-KEM-768>",
"ciphertext_data": "<base64 - AES-256-GCM encrypted Okta user list>",
"nonce": "<base64 - 12 bytes>",
"tenant_id": "ten_01HZ9X2K4MNPQR5STUVWXYZ00",
"algorithm": "ML-KEM-768"
},
"signature": {
"pqc_signature": "<base64 - ~3309 bytes ML-DSA-65>",
"hmac_signature": "<base64 - 64 bytes HMAC-SHA-512>",
"tenant_id": "ten_01HZ9X2K4MNPQR5STUVWXYZ00",
"algorithm": "ML-DSA-65+HMAC-SHA-512"
},
"audit_event_id": "aud_01HZ9XABCDEF"
}client.encryption.decrypt(envelope). Both the ML-DSA-65 signature and the HMAC-SHA-512 signature must pass - QuantaSeal uses a bitwise & check, not short-circuit and.Troubleshooting#
401 - invalid_client
The OAuth2 client secret in QuantaVault is incorrect or has been rotated in Okta. Generate a new client secret in the Okta Admin Console and update the vault entry.
403 - insufficient_scope
The service app does not have the required Okta Management API scope. Add the missing scope in the Okta Admin Console under the app's OAuth2 scopes configuration.