- Aug 2021
-
pragmaticwebsecurity.com pragmaticwebsecurity.com
-
browser environments are ridiculously hard to secure.
Very very true!
-
Instead of using self-contained JWT tokens for access tokens, you can use reference tokens.
I'd be for it but it breaks already mde decisions and flows implemented by SDK and dependen services. Also the revocation of APIML tokens is in place by checking the REVOKED cache (if I'm not mistaken).
-
link the lifetime of that refresh token to the lifetime of the user’s session with the security token service.
Still plenty of time to exercise the hackers rights.
-
Note that this does not give you more security, just a bit more control.
Must admit that more control is a benefit in any case.
-
These cheat sheets for securing Angular applications and React applications can help you with that.
We are on the API (server) side. We can't dependently lean on controlling the FE security.
-
The point I want to make here is that RTR offers the same level of protection than using access tokens with silent renew. It does not make an application less secure, but also not more secure. With that in mind, refresh tokens are a much more beautiful abstraction than the use of iframes, which makes RTR so great.
Declared: Not more secure than the iframe option and it (iframe) is not very secure at all. What they have in commopn is that they implement a workaround for RT in browser. There is a benefit though - it is provided in in the sentence saying smth like: "The real trasure is the AT", so shorter the live of the AT the better.
The only point in favour to RT is that a hacker aware of the RTR and douple spend detection will not be even interested in stealing the RT.
-
Hence, the refresh token allows an application to autonomously obtain a new access token from the security token service, without user intervention.
Although its true, that refreshing token without user interaction is a legal scenario, it is not for UI living in web browser, but rather for the server side apps, perhaps the BEFE.
-