New answers tagged

0

You seem to just store the access tokens server-side and use it's string value to determine whether it is cached to avoid validating the signature again. In theory I don't see anything wrong with this approach although it somehow wrecks the advantages you get from the statelessness provided by bearer tokens. In practice I see a few partially potential issues ...


1

If your current refresh token is valid for multiple uses and expires only once it's lifetime exceeds, you might have issues tracking token replay and revoke the token (I assume that is what you mean with stateful?) Ideally refresh tokens should be one time use only (hence the "nonce" claim). What you can do is refresh token rotation, i.e. issuing a ...


1

Yes, this is insecure. By refreshing the token every time an action is performed, an attacker who stole a token once can essentially enable them to remain authenticated forever. Section 6 of this answer explains this in more detail. Here are some of the most important snippets: In fact, if the token is regenerated every time you do something in the app, ...


2

Posting this as an answer as I cannot comment yet: What is the best way to encrypt each request? I think forcing your server to run on HTTPS should offer enough encryption, as it obscures most information associated for a REST call such as query or form parameters to a point where an eavesdropper can only make vague assumptions about their respective ...


2

Assuming you mean sessions stored in JWT tokens then you are increasing the risk of session hijacking. The concept behind expiring sessions is so if an attacker did gain access to the session token it will be limited or already expired. The refresh token is used if the user logged in is still active and you would like to refresh the session token before it ...


1

oAuth with JWT is usually stateless for the resource servers, which just validates the JWT signature and metadata. The JWT is time limited - signalled through the exp (expiration) attribute. When the token expires, and the user is still active, the client is obliged to fetch a new JWT from the authorization server (AS). It will then usually identify the ...


0

I don't know if it's the same in your case, but when I run into the same problem I realized that the token I was generating on the server had token category INTERNAL, in which case it is hardcoded to HS256 as you can see in the keycloak source code. In my case the solution was to implement a custom token with different TokenCategory. public class ...


Top 50 recent answers are included