Huh, I always forget a lot of programmers weren't around when this stuff was invented. It's all actually pretty simple, and very little complexity. However, there are so many "gotchas" (that can result in zero security) that anyone writing a guide like this would probably have you sign a waiver, then any company you work for sign a waiver, and include your firstborn child.

For example, user/pass is pretty simple on the surface:

1. app sends server user/password.

2. check if it matches the password in the database.

3. if so, respond with a token the app can send back that is associated with the user. if not, return with a 401.

The number of gotchas in this simple 3-step process is insane... here's some off the top of my head (not exhaustive):

- make sure the login form includes a CSRF token.

- do not store the password in plaintext in the db. or encrypted, probably. Since an attacker can possibly get the encryption key and then decrypt all your passwords. Use strong, slow hashes.

- rate limit your logins to prevent brute-forcing (slow hashes work great here)

- use constant-time comparisons to check if the password matches (e.g., hash_equals() in PHP), RTFM for whatever constant time check you are using or you will open yourself up to timing attacks.

That's the issue with security stuff, there are so many gotchas that anyone writing a course would open themselves up to getting sued (at least in the US) just for missing a gotcha or someone with Dunning-Kruger thinking they know everything and getting hacked ... it's too risky. You have to just get into the industry and learn it the hard way. At least that's how I learned everything I learned.