u/michaelnovati replied ·
Lots going on here! There are a few things that if you really go deep on, you'll spend hours/days trying to figure out, and authentication from scratch is one of those. It's a very complex area with many different approaches. I think I spend 10 hours figuring out how Amazon Cognito User Pools vs Identity Pools worked, and people confused them often online so I had to really go to the API docs in detail.
At a zoomed out view what you have is correct, but there are a lot of variations under the hood that might be confusing you.
I am time-boxing my answers here to a minute, but will try to give some directional tips:
1. Whatever is handling authentication requests doesn't have to be "the server", you should think about the specific sequence of actions that need to happen to securely generate and store tokens and not so much who is doing what where. There are dozens of protocols for doing auth, 1Password has a complex scheme to never send "master passwords" anywhere, [https://1passwordstatic.com/files/security/1password-white-paper.pdf](https://1passwordstatic.com/files/security/1password-white-paper.pdf). This might be confusing you even more, so more of a "know what you don't know" thing.
2. Oauth2 is a common protocol that a lot of services use. I'm a big fan of rolling your own approach to understand, and then applying what you learned to an industry standard. So look into that. It often uses "refresh tokens" AND "access tokens" to reduce the chance of stolen tokens.
Now in terms of what you wrote:
1. "Remember Me" doesn't really have anything to do with auth, it's more of a client side decision about when to expire/deal with tokens, but the flows should be the same. For example, if you store the token in a cookie, you might make it expire on page close, a feature of cookies. If you store in local storage, you might have a JS hook on page close that wipes the token from local storage. You're right that it's basically like "client throwsaway the token" to "forget you". If you have a situation where the token could be not expired for a very long time, and you rely on just deleting it to "forget the person", keep in mind the token is still VALID if someone else "stole it".
2. The rest of what you wrote is more or less correct. You can use cookies instead of local storage (and there are good reasons to do so sometimes re: CDNs and access control for static resources). OAuth2 uses a concept of "Refresh Tokens" in addition to the normal access token, to help with dealing with expired tokens, etc...