jti in jwt and stateless?

[Choco-milk-for-u]

OWASP MASTG reccomend you to:

Make sure that replay attacks are addressed with the jti (JWT ID) claim, which gives the JWT a unique identifier.

and also insist on:

If access and refresh tokens are used with stateless authentication, they should be deleted from the mobile device. The refresh token should be invalidated on the server ↗.

basically giving the idea of querying the database when working with JWT. Why can't I use the session if I will have any kind of state anyway?
thank you for the help in advance.

[sushi2k]

Deny lists can be used in scenarios where you need to revoke tokens before they naturally expire, such as when a user logs out, their account is compromised, or roles/permissions change. Refresh tokens are usually long lived (weeks or months) and this is a common way to revoke them.

If you don't need to utilize the features of JWT (for example it can scale more easily, as there’s no need to replicate session data across servers in distributed architectures) a session can also be utilised and should be utilised to not overcomplicate the architecture. In the context of mobile apps JWT can be seen due to the "silent refresh" that can be done through access and refresh tokens without the user logging in again. Also all user-identifying information can be stored in a client-side token, compared to query it from a database for Stateful authentication.

Hope that helps.

[Choco-milk-for-u]

Hi thank you for your response, did I get it right that, unless in specific scenarios such as when using silent refresh for mobile, I should use sessions to avoid overcomplicating the architecture, as a deny list is still considered stateful?

[sushi2k]

It's different factors for JWT vs Session and also how many clients (browser, mobile, 3rd party integration) are using the backend and how the existing architecture looks like:

• I've seen mobile apps that need to talk to legacy/existing backends (e.g. in Java) and therefore needed to use a JSESSIONID
• But, when using a session you need to let the session expire for security reasons (see https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#session-expiration), meaning the user might need to login every day, which is not convenient on a mobile device. Either users will not remember their credentials or use a a weak password. I've seen login flows where you just provide your mail address and click on the login link you got sent in the mail to avoid using credentials, but still you need to have some kind of login flow after the session expires.
• In the context of mobile apps JWTs are used due to the silent refresh. You login once and then you can use access tokens to authenticate against the APIs and use the refresh tokens to get a new access token when the access token expires. This is how Facebook uses long lived tokens: https://developers.facebook.com/docs/facebook-login/guides/access-tokens/get-long-lived/. As long as you use Facebook within 60 days you don't need to login again with your credentials as you always get a new " Long-Lived User Access Token".

When starting a project from scratch JWT can be a good solution for mobile apps to avoid that users need to login every day.

Regardless if JWT or a Session is used you can rely on (local) biometric authentication on the device to login a user, after the initial login with the user credentials.

For example Android supports different kind of authentication mechanisms by using the credential manager and make the user sign in easier in an app: https://developer.android.com/identity/sign-in/credential-manager

[Choco-milk-for-u]

Thanks for the clarification. The conclusion that I understood is that the question is not stateful vs stateless, but technology vs. other technology. If I want to have security, I will still have some state. But with jwt it would be easier to scale and make it less "stateful" in some sense.