Keys, tokens, OAuth, JWT, encryption, and the difference between securing an API and looking like you did.
Set them per consumer and per plan rather than globally, publish them, return them in headers, give people a path to more, and remember rate limits are a business tool as much as a protective one.
Assume they will leak. Scope them narrowly, expire them by default, make rotation and revocation trivial, scan your repositories continuously, and monitor for anomalous use.
Layer it — TLS everywhere, real authentication, least-privilege authorization, input validation from schema, rate limiting, logging and monitoring — and enforce the baseline with governance rules rather than good inte...
Log enough to reconstruct what happened, never log credentials or personal data you do not need, and decide retention deliberately — because an access log is also a surveillance record.
Scopes define what a token may do. Design them around what a consumer is trying to accomplish, publish them as a first-class page, and reference them inline in your documentation.
A token a user can generate for their own account without registering an application. Yes, you should offer one — it removes the single biggest source of onboarding friction in OAuth-based APIs.
The APIs you do not know you have, followed closely by broken object-level authorization on the ones you do. Both are inventory problems before they are code problems.
Because it solves a genuinely hard problem — delegated access without sharing passwords — and because most implementations bolt an application registration and a multi-leg dance onto what the user experiences as "let ...
