Using a persistent httpOnly cookie for authentication? (SPA)

Question

So I'm building an application that needs authentication, I'm wondering if there's an security concerns with using a persistent httpOnly cookie to store user authentication with a SPA? (only 1 server. OAuth is not an option) I could set the duration to say 30 days (is this a reasonable duration or should it be shorter?), then every time the user accesses the site a new token is set. This would mean that users visiting the site more than 30 days apart would need to relogin, but other than that it would be user friendly and secure from my understanding?

One thing I'm not sure about is the format of the token, since typically JWTs can't be revoked from my understanding, so would a long (128bit?) random string be sufficient instead?

User logs in -> Generate token -> Push token to DB with the users ID (1 token per user, remove any existing tokens?) -> Set cookie to token.

User starts browser -> Get token from cookie -> Search DB for matching tokens -> accept / reject

User accesses resource -> Get token from cookie -> Search DB for matching tokens -> Get associated user ID -> Authorize if permitted to access resource

User logs out -> Search DB for token, remove entry

Answer 1

A few thoughts:

• As @ConorMancone points out, this is just basic session management. Approximately every web site in the world that lets you submit credentials once (rather than on every authenticated request) and then stay signed in (whether for minutes or years) is doing some variant on this.
• HttpOnly is not a significant security boundary. You need the Secure flag, which prevents the cookie from being sent over insecure connections. Not that HttpOnly is bad - if you can use it, do so - but all it does is prevent a specific post-exploitation attack if the attacker successfully uses XSS (Cross-Site Scripting). Preventing XSS in the first place is far more important, as it can be used for lots of things besides stealing cookies. You can also use the relatively new "SameSite" flag - probably in "Lax" mode - for CSRF protection.
• The primary use of JWTs is to let servers authenticate clients without storing any state on the server. This is most beneficial for apps that are big enough they are served by a cluster; otherwise, active user sessions are often cached on the server to avoid the extra DB query (but using a cluster means you now have to deal with cache coherency messes). You can also switch what your session token looks like at any time; to the client it's just a meaningless blob that gets included with every request.
• If you want to use random tokens, 128 bits (16 bytes) is good. However, you must use a cryptographically-secure (pseudo-)random number generator to create the token (you'll also need to encode the token as something, like hex or HTTP-safe base64). Every modern OS and web framework offers this.
• Speaking of web frameworks, I can't really recommend rolling your own session management functionality. Just use whatever your framework provides for sessions. It might not be the best, but it'll probably be better than you can create without more knowledge and experience.
• Session duration is a question that REALLY depends on the app, and the clients, too much for us to say here. Some apps, such as banking apps or other very conservative ones, often have a session timeout measured in minutes. Others, such as StackExchange, are good for much longer (looks like the "acct" cookie SE uses is good for 6 months; some sites' cookies are good for years). You can also just not set an expiration, in which case the cookie lasts as long as the browser session (but no longer). Since lots of people don't actually close their browsers these days, those cookies may last until something forces the user to reboot.