Knowledge base
Not a spec walkthrough. Start from your architecture — banking, microservices, Kubernetes, legacy — and find which patterns apply, what breaks in production, and how it lands on PingAM.
Open banking and regulated APIs: PAR, JAR, consent management, and what FAPI actually demands of your authorization server.
A public client handling money: PKCE, app attestation, sender-constrained tokens, and the session model regulators expect.
Applications that will never speak OAuth2 natively: gateway-mediated token handling, header injection, and incremental modernization without a rewrite.
Propagating user identity across service boundaries: delegation, the act claim, and why forwarding tokens is the mistake everyone makes first.
The phantom token pattern: opaque tokens outside, JWTs inside, and the gateway as OAuth2 policy enforcement point.
Where mTLS ends and OAuth2 begins: SPIFFE/SPIRE identities, sidecar token handling, and avoiding two overlapping trust systems.
One identity fabric across on-prem and cloud: cross-domain token exchange, federated authorization servers, and latency-aware token validation.
Workloads as first-class identities: credential lifecycle, rotation, secretless authentication, and one client per service.
From service account token to OAuth2 access token: workload identity federation, projected tokens, and no secrets in the cluster.
Long-running jobs with no user present: whose identity runs the batch, token lifetime strategy, and why offline_access is usually the wrong answer.
The reference page: how every pattern in this catalog maps to PingAM — grant configuration, scope validation plugins, stateless vs. CTS-backed tokens, and PingGateway at the edge.
A user calls service A; service A must call service B on the user's behalf — without token replay.
No user in the loop. Scoping, rotation, and why one client per service actually matters.
The only correct answer for public clients — and the details that still get it wrong.
Long-lived sessions for public clients without long-lived credentials.
Sender-constrained tokens: a stolen token that is useless to the thief.
The revocation-versus-latency trade-off, decided per audience instead of globally.