NHI / Machine-to-Machine Demo — Okta Client Credentials

Configuration

Okta Domain The tenant issuing tokens. No trailing slash. Authorization Server ID The Custom Authorization Server that owns the scope and issues the token. Client Credentials has no user context, so it can't use org-default OIDC scopes — it always needs a Custom AS. Client ID Identifies the calling app/agent itself — this is the "who" in the token, since there's no human "sub" to put there. Client Secret Proves the client is who it claims. Sent Base64-encoded in the Authorization header (Basic auth), never in the request body.

Grant Type client_credentials = machine-to-machine, no user, no redirect, no browser. This is the whole point — everything else (authorization_code, implicit) requires a human to log in somewhere. Scope Custom scope defined on the Authorization Server. Least-privilege: this client should only ever be able to request the scope(s) it actually needs, enforced by the AS's access policy. Client Authentication Method How the client proves its identity to the token endpoint. This demo is wired for client_secret_basic. private_key_jwt (signed JWT instead of a shared secret) is the stronger option for production service accounts — no secret to leak, rotatable via JWKS — but isn't wired into this demo's backend call.

What each piece is for

Authorization Server: Okta object that mints tokens and enforces which client can request which scope, via its access policy + rule.
Access Policy / Rule: Not shown here as a field, but it's what actually grants this Client ID the right to request this Scope with this Grant Type. Configured once in Okta admin, not per-call.
Resource Server: The API being protected (this same box, in this demo) — it independently validates the token's signature, issuer, audience, and scope before doing anything. Okta doesn't do this validation on the resource's behalf.
human_user_involved: false: The field the resource returns to prove no person authenticated anywhere in this chain.

1Call the resource with no token

not run

Proves the endpoint is actually protected before we do anything else.

2Request a token from Okta

not run

Backend does POST https://{Okta Domain}/oauth2/{AS ID}/v1/token with grant_type=client_credentials and scope=..., authenticated with Basic auth (Client ID:Secret, Base64-encoded). No browser, no login page, no human — this call is entirely agent-to-Okta. The response's scp, aud, and sub claims below confirm the client — not a person — is the identity in the token.

3Call the resource WITH the token

not run

Same call as step 1, now carrying Authorization: Bearer <token>. The resource validates it independently and, if valid, executes the action.