Authentication · Verified identity
Basic, Digest and API keys: different security models
Separate encoding, credentials and application keys.
Understand the concept
Basic carries a Base64 encoding of username and password. Encoding is not encryption: captured values can be decoded. HTTPS is necessary but does not prevent every leak through logs, extensions or misconfigured intermediaries. Consider repeated transmission, scope, rotation and attempt limits.
Digest uses challenges and digest calculations, with algorithm and client-support considerations. It is not a universal replacement for modern session or delegated-access designs. An API key often identifies an application or integration rather than a human user with explicit permissions. Its header and access model are application conventions.
Avoid secrets in query strings because URLs spread through history, logs and sharing. Limit permissions, plan revocation, and do not embed private keys in browser bundles. Rate limits, quotas and credential validation solve different problems. Select service credentials according to the actual platform threat model.
When designing third-party and machine-to-machine integrations.
Treating Base64 as encryption or a frontend environment variable as a secret vault.
One topic. Three levels of depth.
Authorization: Basic <base64-user-and-password>A placeholder without real credentials; HTTPS and lifecycle controls are required.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
Will NEXT_PUBLIC_API_SECRET remain private when shipped to a browser?
Show the solution and explanation
No: browser-delivered values are public to the client.No. Private credentials must remain on the server.