MAC vs Encryption
Encryption provides confidentiality, a MAC provides integrity. Using encryption alone makes your messages vulnerable to a ciphertext only attack.
An example will make it more clear. Say you send a message that says:
M = "transfer 100$ to account 591064"
The sender, with the symmetric key, can encrypt the message and send E(M). No one should be able to send a valid message other than the holder of the key. You have confidentiality covered.
But an attacker could alter the ciphertext to make it say something else when decrypted. Obviously, the larger the message and the more structure it has, the harder it gets to carry out in practice.
Now if you use a MAC along with encryption, you will be able to detect changes to the cipher text because the MAC will not compute. In our example, if you use the same key for encryption and MAC, then you can change your message to:
M = "transfer 100$ to account 591064|a46c0db15acdd36b4e92a82e5dc6c14f"
and encrypt it, again sending E(M). The hash is encrypted (that's your MAC), the message is encrypted (for confidentiality). That way, you make it computationally impossible to alter the cipher text and come up with a valid message, even if your message is a single, random byte.
Choosing the best hash, encryption and key length is another story.
In conclusion:
- Encryption does not provide integrity by itself
- MAC (integrity) does not provide confidentiality by itself
You often have to combine cryptographic primitives to achieve many security properties.
@ixe013 explains it well. Encryption and MACs serve a different purpose.
If you need integrity, you need to use a MAC. Encryption does not provide integrity.
If you need confidentiality, you need to use both encryption and a MAC. You might think that encryption would be enough in this case (no need for a MAC), but you'd be wrong. See Don't use encryption without message authentication.
That said, in practice you shouldn't roll your own crypto. That means, among other things, you shouldn't try to build up some combination of cryptographic primitives to achieve your application needs: you shouldn't think at the level of encryption algorithms and message authentication codes. Doing so is error-prone, and rarely is it necessary. Instead, you should use an existing well-vetted cryptographic system (TLS, GPG, SSH, OpenVPN, IPSec, etc.) to provide a secure communication channel or a secure storage system. If you do that, the existing cryptographic system will take care of these details for you. Cryptographers have slaved over these details, so that you don't need to.
A MAC or authentication tag (sometimes also called signature, although I think that's too confusing) can be used to provide message integrity and message authenticity. Message integrity means that an adversary - or transmission error - cannot change the message without it being detected by the receiver. For physical products we would call this tamper evident. Message authenticity shows that the message originated from a sender holding the secret key. Beware that both sides have the same secret.
Entity authentication is something different: the identification and authentication of parties within a protocol often relies on asymmetric cryptography rather than symmetric cryptography. In the TLS protocol the server is generally authenticated using a private key / certificate pair, while the messages are protected by a authentication tag generated using the symmetric session keys.
Most modes of operation will allow an attacker to make changes for specific bits. For instance, in the popular counter mode (CTR mode) any bit can be flipped, which will lead to a flipped bit in the plaintext at the same position. For CBC mode more bits will be changed, but the decryption and unpadding will still be unaffected (unless the last ciphertext block is changed significantly). One of the other answers underestimates the possibility of locally changing the plaintext by changing the ciphertext.
Generally a MAC is used over the ciphertext instead of over the plaintext. One of the reasons is that some modes of operation - such as CBC with PKCS#7 padding - are vulnerable all by themselves. If a padding or plaintext oracle is possible, CBC may actually allow an attacker to retrieve all the plaintext, without even attacking the cipher or gaining information on the key. For more information, see the question about MAC-then-encrypt and encrypt-then-MAC.
A MAC needs to be over both the ciphertext and the nonce or IV. If the IV or nonce are excluded the plaintext may still be altered by an adversary (if it is accessible by said adversary, of course).
Generally we try and use an authenticated cipher or AEAD cipher. These ciphers will automatically include any nonce or IV within the verification, so they should fully protect the plaintext.
Moreover, they may use a fast MAC that is insecure when used by itself, but is secure if it is combined by the cipher. Examples of these faster ciphers are ChaCha20/Poly1305 and AES-GCM. Both are for instance included in TLS 1.3.
There is even the IP hampered OCB mode which only requires a single pass of the cipher over the plaintext to both encrypt and provide integrity / authenticity. The Keccak sponge (used for SHA-3) may also be used for an authenticated mode.
Note that a MAC in itself doesn't protect against all attacks. For instance, if it is used within a transport protocol, it might be that messages are replayed if the same key is used. Furthermore, since a MAC also relies on symmetric keys, it could be that messages from A to B are captured and send back to A.
It is up to the higher level protocol to guard against such conditions. This is one of the reasons why transport security is hard. Just applying a MAC is not enough for a generic transport protocol. For transport security, use TLS, SSH or another established secure transport layer.