I’m one of the few I guess that have implemented OAuth at scale and enjoy it more than other forms of auth. Remember Windows Login Auth? Or each system having to be sync’ed to some sort of schedule so that passwords were the same? Yeah, no, that sucks.

OAuth is just a process framework for doing authentication and authorization such that a system doesn’t need to create those mechanisms themselves but can ask a server for it. More recently, in the form of a JWT token with those permissions encoded within.

It all boils down to how long your login token (some hash), or in the case of OAuth, your refresh token, can request an access token (timeboxed access to the system). “Tokens” in this case are just cryptographic signatures or hmac hashes of something. Preferably with a nonce or client_id as a salt.

Traditional login with username and password gives you a cookie (or session, or both) that you use to identify that login, same thing for refresh tokens. Only, refresh tokens are authentication, you need access so you request an access token from a resource server or api, now you have your time boxed access token that allows you to “Authentication: Bearer <token>” at your resource.

From a server perspective, your resource server could have just proxied the username and password auth to get the refresh token or (what I like to do) check the signature of the refresh token to verify that it came from me. If it did, I trust it, so long as the user isn’t in the ban table. If it’s good and they aren’t banned, issue them a time boxed access token for 24h.

If you fail to grasp the JWT aspect, I suggest you learn more about RSA/PKI/SHA and HMAC encryption libraries in your programming language of choice. Knowing how to bcrypt is one thing, knowing how to encrypt/sign/verify/decrypt is The Way.

(Sorry to the grey beards in the back and they know this already and probably wrote that RFC).