You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Glaring security hole with the code here means that if anyone compromises a single active token, they could remain logged in forever, even if the user changed their password or "logged out".
To fix this, refresh tokens must be implemented, which can be revoked.
The text was updated successfully, but these errors were encountered:
I've not had the need to implement it yet, but the basic concept is you generate a long-lived token which can only be used to request new tokens, not for direct access to the API. The long-lived token will be verified when you access the token-request end-point against revocation data from your underlying data source, before generating a new short-lived token which can then be used to access all your API end-points (which then don't need to check revocation data in your data source).
It's particularly important in the case of an app on a phone, where typically you log in once after installing the app then never again, therefore have a token of some sort which is valid indefinitely. It's less important on a website where you can simply choose to expire logins after a given period and have the user re-log-in. It depends on your use-case.
Glaring security hole with the code here means that if anyone compromises a single active token, they could remain logged in forever, even if the user changed their password or "logged out".
To fix this, refresh tokens must be implemented, which can be revoked.
The text was updated successfully, but these errors were encountered: