Don’t rely on API keys as authentication: API keys are commonplace in the
world of APIs, and they are seen frequently as a means of connecting
partners, connecting client apps to back-end APIs, and enabling machine to
machine (or direct API communication. API keys are easily harvested by
attackers through reverse engineering client-side code and sniffing network
traffic if keys traverse unprotected networks and the Internet. API keys
alone are not a sufficient form of authentication and should be used
primarily as a form of version control. If you rely on API keys, ensure that
you monitor consumption, generate new API keys, and revoke old API keys
or API keys of malicious consumers appropriately. Realistically, API keys
should be paired with additional authentication factors such as certificates
or other authentication material.
4.
Set reasonable idle and max session timeouts: idle session timeout
controls how long a given session with the back-end can stay live without
receiving requests from the client until a user or machine is required to
re-authenticate. Max session timeouts control the total time a session can
be live with the back-end regardless of whether the session is active or idle.
Idle session timeout recommendations range anywhere from 5 to 30
minutes depending on exposure of the API, business criticality, and data
sensitivity. Max session timeouts are usually in the range of a few hours or
days. Some organizations opt for shorter session lifetimes, but such an
approach requires a trade-off with UX since you will be forcing users to
re-authenticate more frequently. You must consider these lifetimes for all
session identifiers, authentication tokens, and refresh tokens throughout
the technology stack. The intent of controlling session timeouts is to reduce
the time window for attackers to steal session identifiers and hijack
authenticated sessions. Active session identifiers and authentication tokens
are just as valuable to an attacker as an original credential and can easily be
used to obtain access to API and data.
5.