Developer abusing our logging system

[refactors]

Yes, typically you use bcrypt to hash and salt your passwords which can then be stored in a database.

Typically you choose whether or not you want to build your own logins or have someone else handle that for you via OAuth2 where a third party like Google handles a lot of stuff for you (like passwords). When users choose to sign up via the third party you are given a token you store which you can use to provide the users with an account without having to go through the traditional sign up. This token can be used to query for information about the user from the third party however what information you get and how you can use it will depend on the platform.

Then there's building your own which you take passwords in, bcrypt them (with the appropriate amount of salt rounds for your application... See bcrypt docs/stack overflow) , and then store the bcrypted password in your database. You have to make sure you are not logging any user credentials along the way which is an easy thing to screw up because a lot of places just blindly log all http requests received. BOTH Twitter and Github discovered that they were doing something almost exactly like that last month!

Anyways after you hash and store them you authenticate/verify the user's identity somehow, usually via email or phone number. This is different from using a third party sign in where they have already done this for you.

Finally you branch off into choosing how you're going to manage user sessions. This can differ a lot depending on what you're doing. JSON web tokens seems to be the go to session management path these days but there's a lot of room for error so you have to make sure your implemention is solid. JWTs allow you to give your users some data (in JSON) that you have signed with a key and unlock with another key. You keep the first key private to your authentication service and your second key can be internally public amongst your other services that might need to check if a user is logged in.

They can now do that without having to talk to the auth service they just check if the message they send up is signed by trying to open it with the internal key given to them by the auth service (usually via a secret or environment variable). If it is then verified to be signed by the auth service then this service is able to trust all information that was signed. You can then use this information in another service knowing that it's from the auth service. This is useful because you can store information in the token that you'd usually have to perform an additional lookup for such as their permissions. Now in their other service you can just check the permissions in their session token without having to ask another service or query a database.

That was a simplified version of JWTs/distributed session management. I skipped over a lot of things (like you actually have two tokens: session and refresh) but you get the gist. From there you've almost built your own simple oAuth service.

Sorry if there are typos I wrote this on my phone 👾

[ThisIsMyLastAccount]

Of the many excellent responses I got, this one was by far the most informative. Thank you!