Authentication in coding essentially serves as a safety net for program or user generated content in the database to ensure that the person attempting to access it is a person who ought to be accessing it. When the user attempts to access a specific piece or group of content, they are sending a request to the app server saying “Hey, I’d like to create/ update/ destroy, may I please?” The authentication is a figurative barrier between the user and that content that the server has to decide whether they are allowed to interact with and in what ways. The request is generally sent in the form of an HTTP header for the program to read, and if, for instance, the user sends a request that doesn’t include in their iauthentication, the server returns an error message saying “If you want to access this, I’m gonna need to see your credentials”. These credentials–the unique authentication– need to match between the user’s stored info and the database’s stored info, so the authentication takes places as essentially a conversation between the two parties. Metaphorically, the server is saying “What’s the secret password?” and the user get request needs to contain that secret password in order to gain entry. The purpose of this is to prevent a person from being able to access or alter information that they should not be able to access or alter.
The other side of this “secret password” is the storage aspect on the program’s side. We use has_secure_password to ensure that if someone were to somehow break into our program, they don’t have access to the users’ stored passwords. Since hackability makes us unable to store the actual password itself, we feed the password wtring into a hash function to essentialy store the password as a complicated set of numbers that secures it on our end. The more complex the hash, the better. Even if we use a hasher like a dumb_hash or Murmur or Bcrypt, there is still the possibility that a talented hacker can gain access to our information, so we add another layer of security by salting the return value of the Bcrypt. Now the password_digest column we added to our users table contains the Bcrypt return value with additional salted values sifted in and stored in a 29 character string. We tell our program to expect this password_digest with has_secure_password, which doesnt search for specific database columns, but for password and password_confirmation, which directs to our salted hashed password stored in the password_digest. Good luck with that.