PS Product SecurityKnowledge Base

🔐 API Authentication and Authorization

Intro: Authentication proves the caller. Authorization limits what that caller can do. Most severe API incidents happen where teams implement the first and assume the second follows automatically.

Authentication versus authorization

Authentication establishes identity. Authorization decides whether that identity may call this route, access this object, see this field, or perform this workflow transition. Do not let a valid token become a blanket permission model.

Core patterns

  • centralize identity verification where it reduces inconsistency;
  • keep authorization decisions close to business objects and workflow state;
  • use short-lived credentials with clear audience and scope;
  • treat internal APIs as still needing trust boundaries.

High-risk mistakes

  • trusting client-supplied identifiers or tenant IDs;
  • checking route-level access but not object ownership;
  • long-lived static credentials shared across services;
  • relying on hidden frontend controls as if they were access control.

Modern protocol and implementation notes

OAuth and OIDC defaults

For user-delegated API access, prefer Authorization Code + PKCE instead of older browser-heavy shortcuts. Treat older grants such as the implicit grant or resource-owner-password flow as legacy patterns to migrate away from.

Scopes are not permissions

A scope tells you roughly what kind of token was issued. It does not automatically prove:

  • object ownership;
  • tenant membership;
  • field-level visibility;
  • workflow-specific authority.

JWTs versus introspection

Self-contained tokens can reduce lookup latency, but introspection or phantom-token patterns often give you better revocation, policy agility, and central auditability. Choose deliberately instead of defaulting to JWT everywhere.

Service-to-service callers need a separate review path

Non-human identities deserve their own controls:

  • narrow audience and scope;
  • short lifetime;
  • workload identity or mTLS where practical;
  • no shared static secrets if they can be avoided.

Review questions

  • What identities can call this API?
  • What proves those identities?
  • What object-level checks are performed server-side?
  • Do support, admin, or automation callers use separate policy paths?

Release checks

  • authn method documented for each caller type
  • route-level, object-level, and field-level checks reviewed
  • tenant-isolation tests executed with foreign identifiers
  • non-human credentials reviewed for scope and lifetime

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.