Happens all the time, where access is through a low privilege user, or the nature of the infiltration isn't just a user but through some specific tool that only itself has access to specific things. Maybe the hack gets you into Splunk and that's it, and only for a few hours because the session you hijacked expires...
Nobody exposes access tokens on purpose, there is no "its job includes creating access tokens". No system's job results in this happening as part of normal operation.
Also 100% wrong re: "it definitely has access to the database that stores user accounts". That statement makes me think you have no clue what you're talking about; you don't need access to users at all to validate a session token. In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.
I've written auth services that have zero access to password data, which validate session tokens.
> In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.
JWT is a particular type of token. Not everyone uses JWTs because they have drawbacks — in particular, a self-contained signed token can't be revoked without maintaining some sort of blacklist of invalidated tokens. So you have to resort to expiration to make up for that I guess?
In my own backend projects I use session IDs that are simply long random strings that are stored in the database. I delete the row when the user logs out of their session.
A hacker would start salivating if they heard someone who built a product storing PII said what you just did about session tokens for your personal projects.
By the way, social media services like Facebook do store PII and have non-expiring sessions. And somehow, if someone's account is hacked, it's that person's problem, not Facebook's.
Nobody exposes access tokens on purpose, there is no "its job includes creating access tokens". No system's job results in this happening as part of normal operation.
Also 100% wrong re: "it definitely has access to the database that stores user accounts". That statement makes me think you have no clue what you're talking about; you don't need access to users at all to validate a session token. In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.
I've written auth services that have zero access to password data, which validate session tokens.