okta v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-okta-ssws-token

Custody

customer_vault

Injection

header (Authorization)

An Okta SSWS API token for the customer's own org, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'SSWS', one separating space, then the token — 'SSWS <token>'. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. SSWS tokens are long-lived, unscoped, and inherit the full permissions of the admin who created them (tracking that admin's privilege changes): create the token from a dedicated least-privilege admin service account. Okta expires a token after 30 days without use — the 30-day window refreshes with each API call — and deprovisions the token if the creating admin is deactivated; tokens can also be revoked in the Admin Console at any time, and an expired or revoked value fails closed. Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself. Prefer OAuth 2.0 service-app authentication with scoped access tokens where the deployment supports it; review token rotation and the creating admin's role before enabling. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• okta-org-users (api, pii): https://okta-org.invalid/api/v1/users
• okta-org-groups (api, internal): https://okta-org.invalid/api/v1/groups

The endpoint host 'okta-org.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Okta org host (or configured custom domain) before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Every endpoint here is on the customer org host, not a shared Okta SaaS host, so the allowlist moves with the tenant. This pack registers only endpoints the public Okta Management API documents (verified against the official OpenAPI spec that builds Okta's management SDKs): listing and reading users, listing groups, listing a group's member users, adding and removing a user in a group, and the user lifecycle deactivate operation. Documented exclusions: user creation and profile update (POST /api/v1/users, POST/PUT /api/v1/users/{id}), permanent user deletion (DELETE /api/v1/users/{id} — Okta documents it as unrecoverable and it is the truly irreversible off-boarding step), suspend/unsuspend, session clearing and password operations, group creation and group-rule management, and application assignment APIs — a documented exclusion, not an approximated capability. Tiering rationale: identity changes are high-blast-radius. Lifecycle deactivation is registered as delete at the R3 floor: Okta documents deactivation as a destructive operation — the user is deprovisioned from all assigned applications, which may destroy their data such as email or files, and Okta states the action cannot be recovered; the directory account can later be reactivated, but reactivation does not restore deprovisioned application data, so this pack makes no general-reversibility claim, and delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). Group membership assignment is declared update and share at the R3 floor because membership can grant application access, roles and policies downstream — assigning membership is access-granting — and an R2 variant would require an enforced, reviewed restriction to groups that grant nothing, which this pack does not register. Membership removal is declared delete at the R3 floor: the operation deletes the membership relationship itself, and where the group granted access the removal revokes it; re-adding the user later is a new assignment, not an undo of this call. The floors are lower bounds, not risk assessments. The pack registers an SSWS API token because it is the auth scheme every Okta org supports, but SSWS tokens are long-lived, carry the permissions of the creating admin, and are not scoped; OAuth 2.0 service-app authentication with scoped tokens (okta.users.read, okta.groups.read, okta.users.manage, okta.groups.manage — the minimum per capability) is the better-hygiene path and the deployment should prefer it where available. AAES has not been certified by Okta; the endpoints here are a reviewable default, not a vendor guarantee.

Review completed: 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developer.okta.com/docs/reference/core-okta-api/ (retrieved 2026-09-21)
• https://developer.okta.com/docs/api/openapi/okta-management/management/tag/User/ (retrieved 2026-09-21)
• https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Group/ (retrieved 2026-09-21)
• https://developer.okta.com/docs/api/openapi/okta-management/management/tag/UserLifecycle/ (retrieved 2026-09-21)
• https://github.com/okta/okta-management-openapi-spec/blob/master/dist/current/management-minimal.yaml (retrieved 2026-09-21)
• https://developer.okta.com/docs/guides/create-an-api-token/main/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.