A stolen access token can threaten an account regardless of whether the application is signed or protected. Design storage, lifetime, usage binding and revocation together.
Evaluation approach
Review token scope, expiration, storage and revocation. Binding to a key or device may reduce risk while adding complexity to recovery.
Application example
After a suspicious-device event, consider restricting the affected session and sensitive operations instead of signing out every customer.
Limits and considerations
A short access-token lifetime is insufficient on its own; refresh tokens need protection too.
The lifetime of bearer authority
The impact of a stolen access token depends on its scope, lifetime and revocation mechanism. Review logs, clipboard use and diagnostic sharing alongside secure storage. Code review alone should not justify an assumption that tokens never leave the application.
Test server treatment of tokens after sign-out and device revocation. RASP events may help restrict a high-risk session, but the session lifecycle must retain its own controls.
Checks and decisions
- Narrow token scope
- Test revocation
- Prevent log disclosure
Correlate session events with application integrity without treating either as proof of the other.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.