Revoking JWT with No Expiration









up vote
0
down vote

favorite












I'm looking to employ token-based authentication for a mobile app that keeps the user logged in as long as they have not logged out. My approach is to create a JWT refresh token when the user logs in/signs up; This token never expires, and continues to refresh 20 minute access tokens.



The problem arises when they log out. I've read the best way to go about this is to blacklist the JWT on Redis to store revoked keys. However, since the JWT never expires, the record can never be removed from Redis and can start to chunk a lot of my memory.



Should I be worried about this, or is Redis memory-efficient on this respect? Is there a better way to revoke JWT with no expiration?










share|improve this question

























    up vote
    0
    down vote

    favorite












    I'm looking to employ token-based authentication for a mobile app that keeps the user logged in as long as they have not logged out. My approach is to create a JWT refresh token when the user logs in/signs up; This token never expires, and continues to refresh 20 minute access tokens.



    The problem arises when they log out. I've read the best way to go about this is to blacklist the JWT on Redis to store revoked keys. However, since the JWT never expires, the record can never be removed from Redis and can start to chunk a lot of my memory.



    Should I be worried about this, or is Redis memory-efficient on this respect? Is there a better way to revoke JWT with no expiration?










    share|improve this question























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I'm looking to employ token-based authentication for a mobile app that keeps the user logged in as long as they have not logged out. My approach is to create a JWT refresh token when the user logs in/signs up; This token never expires, and continues to refresh 20 minute access tokens.



      The problem arises when they log out. I've read the best way to go about this is to blacklist the JWT on Redis to store revoked keys. However, since the JWT never expires, the record can never be removed from Redis and can start to chunk a lot of my memory.



      Should I be worried about this, or is Redis memory-efficient on this respect? Is there a better way to revoke JWT with no expiration?










      share|improve this question













      I'm looking to employ token-based authentication for a mobile app that keeps the user logged in as long as they have not logged out. My approach is to create a JWT refresh token when the user logs in/signs up; This token never expires, and continues to refresh 20 minute access tokens.



      The problem arises when they log out. I've read the best way to go about this is to blacklist the JWT on Redis to store revoked keys. However, since the JWT never expires, the record can never be removed from Redis and can start to chunk a lot of my memory.



      Should I be worried about this, or is Redis memory-efficient on this respect? Is there a better way to revoke JWT with no expiration?







      authentication oauth-2.0 jwt






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 10 at 19:53









      Daniel Chen

      446




      446






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote













          A JWT token is a self contained token. That means that it lives on its own until it expires and can't be revoked. So by definition it must expire. Because when it falls into the wrong hands, it'll give access to your resources without being able to revoke it. So yes, you should be worried with this implementation.



          The problem here is that you trust the refresh token itself, because it's a JWT. You should in fact trust the server. Not because the JWT can't be trusted, but because the refresh token doesn't have to be a JWT.



          Save refresh tokens in memory including the expiration time. You can remove expired tokens from memory. This means that only tokens that exist in memory can be used to request a new access token. And to be on the safe side, use one-time only refresh tokens.



          The flow would be something like this:



          1. the user logs in, receives a JWT access token (5 minutes) and the refresh token 1 code (48 hours). Refresh token 1 is saved on the server.

          2. five minutes later: the access token expires

          3. a new access token is requested using refresh token 1.

          4. user receives a new access token (5 minutes) AND the refresh token 2 code (48 hours). Token 1 is removed from memory and token 2 is added to memory.

          5. and this goes on for several hours.

          6. For two days the user doesn't use the app

          7. 50 hours later: because both tokens are expired, the user has to login again. Resetting the flow.

          On logout remove the refresh token from memory. And if in the meantime you wish to revoke access. Simply remove the refresh token from memory. Within 5 minutes the user has to login again.






          share|improve this answer






















          • The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
            – Daniel Chen
            Nov 11 at 3:19











          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53242831%2frevoking-jwt-with-no-expiration%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          0
          down vote













          A JWT token is a self contained token. That means that it lives on its own until it expires and can't be revoked. So by definition it must expire. Because when it falls into the wrong hands, it'll give access to your resources without being able to revoke it. So yes, you should be worried with this implementation.



          The problem here is that you trust the refresh token itself, because it's a JWT. You should in fact trust the server. Not because the JWT can't be trusted, but because the refresh token doesn't have to be a JWT.



          Save refresh tokens in memory including the expiration time. You can remove expired tokens from memory. This means that only tokens that exist in memory can be used to request a new access token. And to be on the safe side, use one-time only refresh tokens.



          The flow would be something like this:



          1. the user logs in, receives a JWT access token (5 minutes) and the refresh token 1 code (48 hours). Refresh token 1 is saved on the server.

          2. five minutes later: the access token expires

          3. a new access token is requested using refresh token 1.

          4. user receives a new access token (5 minutes) AND the refresh token 2 code (48 hours). Token 1 is removed from memory and token 2 is added to memory.

          5. and this goes on for several hours.

          6. For two days the user doesn't use the app

          7. 50 hours later: because both tokens are expired, the user has to login again. Resetting the flow.

          On logout remove the refresh token from memory. And if in the meantime you wish to revoke access. Simply remove the refresh token from memory. Within 5 minutes the user has to login again.






          share|improve this answer






















          • The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
            – Daniel Chen
            Nov 11 at 3:19















          up vote
          0
          down vote













          A JWT token is a self contained token. That means that it lives on its own until it expires and can't be revoked. So by definition it must expire. Because when it falls into the wrong hands, it'll give access to your resources without being able to revoke it. So yes, you should be worried with this implementation.



          The problem here is that you trust the refresh token itself, because it's a JWT. You should in fact trust the server. Not because the JWT can't be trusted, but because the refresh token doesn't have to be a JWT.



          Save refresh tokens in memory including the expiration time. You can remove expired tokens from memory. This means that only tokens that exist in memory can be used to request a new access token. And to be on the safe side, use one-time only refresh tokens.



          The flow would be something like this:



          1. the user logs in, receives a JWT access token (5 minutes) and the refresh token 1 code (48 hours). Refresh token 1 is saved on the server.

          2. five minutes later: the access token expires

          3. a new access token is requested using refresh token 1.

          4. user receives a new access token (5 minutes) AND the refresh token 2 code (48 hours). Token 1 is removed from memory and token 2 is added to memory.

          5. and this goes on for several hours.

          6. For two days the user doesn't use the app

          7. 50 hours later: because both tokens are expired, the user has to login again. Resetting the flow.

          On logout remove the refresh token from memory. And if in the meantime you wish to revoke access. Simply remove the refresh token from memory. Within 5 minutes the user has to login again.






          share|improve this answer






















          • The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
            – Daniel Chen
            Nov 11 at 3:19













          up vote
          0
          down vote










          up vote
          0
          down vote









          A JWT token is a self contained token. That means that it lives on its own until it expires and can't be revoked. So by definition it must expire. Because when it falls into the wrong hands, it'll give access to your resources without being able to revoke it. So yes, you should be worried with this implementation.



          The problem here is that you trust the refresh token itself, because it's a JWT. You should in fact trust the server. Not because the JWT can't be trusted, but because the refresh token doesn't have to be a JWT.



          Save refresh tokens in memory including the expiration time. You can remove expired tokens from memory. This means that only tokens that exist in memory can be used to request a new access token. And to be on the safe side, use one-time only refresh tokens.



          The flow would be something like this:



          1. the user logs in, receives a JWT access token (5 minutes) and the refresh token 1 code (48 hours). Refresh token 1 is saved on the server.

          2. five minutes later: the access token expires

          3. a new access token is requested using refresh token 1.

          4. user receives a new access token (5 minutes) AND the refresh token 2 code (48 hours). Token 1 is removed from memory and token 2 is added to memory.

          5. and this goes on for several hours.

          6. For two days the user doesn't use the app

          7. 50 hours later: because both tokens are expired, the user has to login again. Resetting the flow.

          On logout remove the refresh token from memory. And if in the meantime you wish to revoke access. Simply remove the refresh token from memory. Within 5 minutes the user has to login again.






          share|improve this answer














          A JWT token is a self contained token. That means that it lives on its own until it expires and can't be revoked. So by definition it must expire. Because when it falls into the wrong hands, it'll give access to your resources without being able to revoke it. So yes, you should be worried with this implementation.



          The problem here is that you trust the refresh token itself, because it's a JWT. You should in fact trust the server. Not because the JWT can't be trusted, but because the refresh token doesn't have to be a JWT.



          Save refresh tokens in memory including the expiration time. You can remove expired tokens from memory. This means that only tokens that exist in memory can be used to request a new access token. And to be on the safe side, use one-time only refresh tokens.



          The flow would be something like this:



          1. the user logs in, receives a JWT access token (5 minutes) and the refresh token 1 code (48 hours). Refresh token 1 is saved on the server.

          2. five minutes later: the access token expires

          3. a new access token is requested using refresh token 1.

          4. user receives a new access token (5 minutes) AND the refresh token 2 code (48 hours). Token 1 is removed from memory and token 2 is added to memory.

          5. and this goes on for several hours.

          6. For two days the user doesn't use the app

          7. 50 hours later: because both tokens are expired, the user has to login again. Resetting the flow.

          On logout remove the refresh token from memory. And if in the meantime you wish to revoke access. Simply remove the refresh token from memory. Within 5 minutes the user has to login again.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 10 at 23:29

























          answered Nov 10 at 23:24









          Ruard van Elburg

          5,09321125




          5,09321125











          • The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
            – Daniel Chen
            Nov 11 at 3:19

















          • The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
            – Daniel Chen
            Nov 11 at 3:19
















          The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
          – Daniel Chen
          Nov 11 at 3:19





          The refresh token will not give access to resources, only to the auth server to get an access key. Also for mobile apps, it is common practice to not log you out at all. Like Facebook or Snapchat, you stay logged in forever. How would you recommend to implement this capability?
          – Daniel Chen
          Nov 11 at 3:19


















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53242831%2frevoking-jwt-with-no-expiration%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Use pre created SQLite database for Android project in kotlin

          Darth Vader #20

          Ondo