Pow renewal_token - How long is it valid?

Pow is well documented, if you are using the Pow.Plug.Session, then you can find information on that here Pow.Plug.Session — Pow v1.0.39

You have two configuration, session renewal, and the credential cache ttl.

To elaborate on @Schultzer’s answer.

The PowPersistentSession.Plug.Base documentation specifies the following:

:persistent_session_ttl - integer value in milliseconds for TTL of persistent session in the backend store. This defaults to 30 days in miliseconds.

See this post by @danschultzer for more information.

Thanks, tomalexhughes.

If I understand this correctly,

• Pow.Store.CredentialsCache ttl specifies how long the access_token is valid. 30 mins seems to be the default and thats what I am seeing as well.
• persistent_session_ttl specifies how long the renewal_token is valid. 30 days seems to be the default. I have not verified this completely, but renewal_token seems valid for a long time and I am able to renew the session with renewal_token even after few days.

Is my understanding is correct? If not, please correct me.

Also, few observations about the following.

session_ttl_renewal - I am confused about the documentation for this.

• Doc says, its the ttl to trigger renewal of the session and default is 15 mins - However, I am able to renew the session any time after the session created.
• Doc says, its used when the session token becomes stale and a new session has to be created for the user - What does this mean? Is it the ttl to renew the session after it becomes stale/deleted?
• Doc says, if session_ttl_renewal is set to zero, the new session will be regenerated on every request - I am able to renew/regenerate the session with renewal_token on every request. Does this mean, zero is the default value for session_ttl_renewal instead of 15?

Finally, with Pow when I stop the phx.server, all the tokens(both access_token and renewal_token) become invalid. However with Guardian, I used to see that jwt token was valid even after restarting phx.server. Is that the expected behaviour with Pow and Guardian accordingly?

Is my understanding is correct? If not, please correct me.

I think so, I’m still learning myself but that is the conclusion I came too.

Finally, with Pow when I stop the phx.server, all the tokens(both access_token and renewal_token) become invalid. However with Guardian, I used to see that jwt token was valid even after restarting phx.server. Is that the expected behaviour with Pow and Guardian accordingly?

I haven’t used Guardian so I cannot comment on that but I have found this section of the Pow documentation that states the following:

By default the Pow.Store.Backend.EtsCache will be used as the cache backend. In production, this would mean that all session data will be lost between deploys or server restarts. Furthermore, in clusters, the sessions will not be shared between nodes.

I presume this is why tokens are lost between server restarts.

For your remaining questions I don’t have the answers as I’m still learning.

Thanks tomalexhughes, for your useful insights and references.

Just one more thing that I’ve picked up on whilst experimenting, my above comment regarding PowPersistentSession.Plug.Base does not apply if you follow the How to use Pow in an API tutorial. This is because that tutorial has you create a custom plug.

However, the custom plug in that tutorial does have us making use of PowPersistentSession.Store.PersistentSessionCache which uses Pow.Store.Base. This module does some funky stuff with macros to dynamically add the put/3 method to PowPersistentSession.Store.PersistentSessionCache.

The put/3 method is called within our custom plug when creating a new renewal token. To configure the TTL on the renewal token I just modified the config passed, like so:

    PersistentSessionCache.put(
      Keyword.put(store_config, :ttl, renewal_token_ttl_ms()),
      renewal_token,
      {[id: user.id], [access_token: access_token]}
    )

There’s still a few things I am unclear on. Firstly I am not sure whether what I am doing is best practice. Secondly, I’m not sure where the TTL is actually stored; I presume the TTL is part of the metadata of each token and therefore each token could have a different TTL.

This is all based off Pow 1.0.20.