How can an authentication token provide persistence?¶
An authentication token can provide persistence by allowing continued access after the original login or password is no longer usable.
Avoid the dangerous assumption¶
The dangerous assumption is that changing the password automatically invalidates every token and session.
It may not.
A token may allow:
- continued user access
- API access
- application access
- session renewal
- service-to-service activity
- access from a trusted device.
Investigators should identify:
- the token type
- issuing provider
- account or application represented
- permissions
- creation time
- device or session association
- use history
- refresh activity
- expiry
- revocation.
The exact behaviour depends on the provider and should be checked against current documentation.
A token may have been stolen, legitimately issued to a malicious application or created through an already compromised session.
The presence of a token does not prove it was used.
Likewise, activity after a password reset does not automatically prove token persistence. Another account, session or application may explain it.
Preserve provider audit logs, token or session identifiers, consent records and revocation actions.
Do not record or distribute secret token values unnecessarily.
A token can make malicious activity appear as valid account or application use.
Some tokens are tied to a device, application or session, while others may be usable elsewhere. That distinction affects both containment and attribution, so avoid assuming transferability without provider-specific evidence.
Preserve token-related sign-in and API events before retention expires, because later revocation may not reconstruct earlier use.
Operational takeaway¶
Identify the token’s account, application, permissions and lifecycle, and verify provider-specific revocation behaviour before concluding that access ended.