3 ms·

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 t

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).

mstaoru 8mo ago
I guess it says something about OAuth when you implement it "at scale" and still have multiple misconceptions (all very common though). Most importantly, OAuth is an authorization framework, OIDC is an authentication extension built on top. Refresh tokens are part of authorization, not authentication. HTTP header is Authorization: Bearer..., not Authentication. There's no such thing as "HMAC encryption", it's a message authentication code. RSA in OAuth is also typically used for signing, not encryption. Not much "encryption" encryption going on in OAuth overall TBH. Nonce and client IDs are not "salts", but ok that's nitpicking :)
- reactordev 8mo ago
  Baby steps my guy, baby steps. Yes, I don’t even mention OIDC, but I think the way I explained it was the middle schoolers version we all can understand (even if there are some minor mistakes in nomenclature). The point I was trying to make at 2am is that it’s not scary or super advanced stuff and that you can get away with OAuth-like (as so many do). But yes, OAuth is authorization, OIDC is authentication. The refresh token is an authorization but it makes sense to people who have never done it to think of it as a “post-login marker”.

mstaoru 8mo ago

I guess it says something about OAuth when you implement it "at scale" and still have multiple misconceptions (all very common though). Most importantly, OAuth is an authorization framework, OIDC is an authentication extension built on top. Refresh tokens are part of authorization, not authentication. HTTP header is Authorization: Bearer..., not Authentication. There's no such thing as "HMAC encryption", it's a message authentication code. RSA in OAuth is also typically used for signing, not encryption. Not much "encryption" encryption going on in OAuth overall TBH. Nonce and client IDs are not "salts", but ok that's nitpicking :)

reactordev 8mo ago
Baby steps my guy, baby steps. Yes, I don’t even mention OIDC, but I think the way I explained it was the middle schoolers version we all can understand (even if there are some minor mistakes in nomenclature). The point I was trying to make at 2am is that it’s not scary or super advanced stuff and that you can get away with OAuth-like (as so many do). But yes, OAuth is authorization, OIDC is authentication. The refresh token is an authorization but it makes sense to people who have never done it to think of it as a “post-login marker”.