Cookie Management Best Practices

[hdmoreland]

Background

I am building the backend to my web app using FastAPI and Postgres, and I am handling authentication using CookieTransport and DatabaseStrategy. My frontend is built with Svelte.

Current Implementation

By default I am returning a Session Cookie on login, where no expiration is set. I also allow users to check a "Keep me logged in" box which will set a Persistent Cookie with an expiration date baked into the Cookie of 30 days. When defining my DatabaseStrategy I am setting a lifetime_seconds equivalent to 30 days, so under no circumstances can a token be valid for longer than 30 days. I elected to implement this strategy after seeing it mentioned by @frankie567 here.

session_transport = CookieTransport(cookie_name="session", cookie_max_age=None)
cookie_transport = CookieTransport(cookie_name="cookie", cookie_max_age=2592000)

def get_database_strategy(
    access_token_db: AccessTokenDatabase[AccessToken] = Depends(get_access_token_db),
) -> DatabaseStrategy:
    return DatabaseStrategy(access_token_db, lifetime_seconds=2592000)

With this design the token for both Session and Persistent Cookies are exclusively removed from my database when a user logs out. They are not removed even after 30 days when they are no longer valid. At the application level both are technically valid for 30 days because of my lifetime_seconds, the only difference is how the browser holds on to the token by default (meaning they could always be modified by the user at the browser level). Is this a standard/acceptable practice?

Questions

I have a few general practice questions I would like input on:

• Is 30 days longer than preferred for a lifetime_seconds value? Is my method here a poor security practice?
• Should I configure an automation to delete tokens from my accesstoken table with a background job or database trigger to kill tokens older than 30 days?
• Should I create a second get_database_strategy for my "Session Cookie" tokens with a lower lifetime_seconds value than 30 days, while keeping the Persistent Cookie Token strategy at 30 days?
• Should I build an endpoint to "Log out everywhere" that removes all tokens for that user from the accesstoken table?
• Should I extend the accesstoken model to include a "last_used" time (indicating the last time a request was made with that token) and "token_type" (indicating the token is attached to a session or persistent cookie), so I can automatically delete Session tokens after a certain amount of inactivity rather than strictly 30 days or is that excessive?
• When a user makes a request with a Session or Persistent Cookie that comes back as unauthorized/expired, should the application also remove the cookie from their browser or should I just redirect to the login page on the frontend where they can reattempt the login?

Overall my goal is a secure application that follows best practices, but I am really striving for simplicity for internal resource reasons within my company. This is which is why I am so hesitant to expand the fastapi-users package itself. I am also not wanting to over engineer for problems I don't have yet, which is why I elected to store the tokens in Postgres (which I am already using heavily) instead of implementing the RedisStrategy or Redis Caching.

[frankie567]

Hi @hdmoreland 👋

Thank you for your clear and complete question. Here are my thoughts:

If your goal is simplicity, I would suggest to implement only one cookie mechanism. Many websites nowadays implicitly remember the user by using a cookie without the Remember me checkbox.

Now, to answer your questions:

• Is 30 days longer than preferred for a lifetime_seconds value? Is my method here a poor security practice?

It depends on the criticality of your application and sensitivity of the actions/data your users will manipulate. 30 days seems a bit long to me, but you should consider the trade-off between security and usability. Personally, I usually set this to 7 days.

• Should I configure an automation to delete tokens from my accesstoken table with a background job or database trigger to kill tokens older than 30 days?

Not necessarily: the access token creation date is stored in the DB, so even if the token is still present in DB, we always check if it's not expired.

Implementing this automation is useful if you want to keep your house tidy and not accumulate too much expired tokens.

• Should I create a second get_database_strategy for my "Session Cookie" tokens with a lower lifetime_seconds value than 30 days, while keeping the Persistent Cookie Token strategy at 30 days?

As I mentioned above, I'm not sure you need the "Session cookie" mechanism. But if you really want it, I would say yes, it's safer to have a strategy that considers tokens with a shorter lifetime (like 24 hours).

• Should I build an endpoint to "Log out everywhere" that removes all tokens for that user from the accesstoken table?

If you really want to be extra-careful about security, yes. Personally, I would say it's not strictly necessary in a first intent.

• Should I extend the accesstoken model to include a "last_used" time (indicating the last time a request was made with that token) and "token_type" (indicating the token is attached to a session or persistent cookie), so I can automatically delete Session tokens after a certain amount of inactivity rather than strictly 30 days or is that excessive?

That would add lot of complexity to your implementation; I'm not sure it would add so much security to the system.

• When a user makes a request with a Session or Persistent Cookie that comes back as unauthorized/expired, should the application also remove the cookie from their browser or should I just redirect to the login page on the frontend where they can reattempt the login?

You could, but not strictly necessary in my opinion.

Hope it helps!