OAuth 2.0

Token lifecycle

Validate access tokens correctly, rotate refresh tokens atomically, and revoke credentials when access is no longer required.

Access-token validation

Validate the JWT signature using the published JWKS.
Require the expected issuer, audience and signing algorithm.
Check expiry, token use and required scopes.
Respect server-side revocation checks performed by ThreatPrevent endpoints.
Refresh cached signing keys when an unfamiliar kid is encountered.

Signing keys

GET https://api.threatprevent.io/.well-known/jwks.json

Refresh-token rotation

Refresh request

curl -sS -X POST https://api.threatprevent.io/oauth/token \
+  -u 'CLIENT_ID:CLIENT_SECRET' \
+  -H 'Content-Type: application/x-www-form-urlencoded' \
+  --data-urlencode 'grant_type=refresh_token' \
+  --data-urlencode 'refresh_token=CURRENT_REFRESH_TOKEN'

Replace the stored refresh token with the new token returned by every successful exchange. Reusing an already exchanged token is treated as suspected replay and revokes the token family.

Revocation

POST /oauth/revoke accepts a token and optional token_type_hint. Authenticate the OAuth client using its registered method.

Introspection

POST /oauth/introspect returns whether a token is active and its authorised metadata. This endpoint also requires client authentication.

Never log access tokens, refresh tokens, authorization codes, device codes, client secrets or complete Authorization headers.