I cannot come up with a case where there is only one of them.
When there is integrity, a random person cannot modify the message without being noticed. That is, an unauthenticated user cannot modify the message without being noticed. Therefore there is authentication.
When there is authentication, nobody except the sender can change the message after MAC or signature is added. Therefore there is integrity.
Am I missing something?
There's a serious overlap between integrity and authentication in the context of exchanging messages, as the other answers correctly note.
However, look at the risks that apply to data in rest (not data in transit) - for a database, the authentication risks (an unauthorised user being able to read and/or write what they should not be able to) are quite separate from the integrity risks, which include all kinds of data corruption caused by accidental software bugs or hardware failures, and these risks need to be properly accounted and mitigated in rather different ways.
Example of integrity without authentication
You download a file and a corresponding checksum over HTTP, and an attacker intercepts both the file, and the checksum. You compare the checksum of the received file with the expected checksum, and it correctly shows that the file is intact. It shows you received what you were intended to receive, but not that the sender is authentic.
Example of authentication, but without integrity
You download a file via HTTPS using TLS (no checksum), but there is an I/O read error on the sender's side prior to transmission, and you receive a corrupted file. In this case you can be sure the sender is authentic, yet there is no integrity of what you received.
Summary
Integrity shows that you received what you were intended to receive (by whomever). Authentication shows that the sender is who he says he is.
You are not missing anything. There is no meaningful distinction in cryptography between ‘integrity’ and ‘authentication’ of data on a channel between two parties. Any attempts at distinction in the context of an adversary wallow in confusion of epistemology without a difference. (If you really like the cute acronym CIA for spook stuff, maybe use the A for ‘availability’ instead!)
The words are not entirely synonymous, of course—for example, a dishonest politician does not lack ‘authentication’, and logging into your bank's web site is not doing ‘integrity’—but it sounds like you're asking how they apply a protocol in which there are three things:
Alice's goal is to transmit a message to Bob using the channel. Presumably, the channel is subject to malicious tampering by an adversary; otherwise there's no security question here. Presumably, Alice and Bob know something about one another a priori; otherwise when Bob receives a message there is necessarily no way he can distinguish a message Alice sent from a message the adversary sent!
Under what circumstances, then, does the protocol have authentication or integrity? Either way, what it means is that—whatever steps Alice takes to send a message, and however Bob verifies the authenticity of a message—the probability that an adversary succeeds in fooling Bob into accepting a forgery is negligible.
In cryptography, we formalize the notion of ‘authentication’ or ‘integrity’ with the EUF-CMA game—existential unforgeability under chosen-message attack. In the EUF-CMA game, Mallory, our heroic adversary, can ask Alice to send any message of Mallory's choice, in order to study how Alice is authenticating messages. Mallory wins the game if they can fool Bob into accepting any message Alice didn't send. Mallory would win the game even if the message is totally meaningless to Bob. The protocol is said to provide EUF-CMA security if the probability that Mallory wins this game is negligible no matter how clever they are.
The EUF-CMA criterion applies to both symmetric-key authenticators, also known as message authentication codes, and public-key signatures; the main difference between authenticators and signatures is whether the power to send a message is the same as the power to verify a message, or whether the powers are asymmetric so that when Alice signs a message, anyone—Bob or any third party—can verify it too.
Outside cryptography, one might reasonably consider a sort of unintelligent adversary—a channel with random noise—and one might use an error-detecting or error-correcting code to provide integrity, meaning that the probability of undetected corruption is substantially smaller with the code, whereas the term authentication doesn't really come up in coding theory at all, so there's no contrast to make between the terms in that context. One might even use a ‘cryptographic hash function’ like SHA-256, truncated if you have limited bandwidth, but one would be better off with a CRC.
When there is integrity, a random person cannot modify the message without being noticed. That is, an unauthenticated user cannot modify the message without being noticed.
Sure. But none of this tells you who produced the message in the first place. So ensuring the message's integrity is not enough to prove that it's authentic.
For example, if you know the expected hash of a file, and you check that the file's actual hash matches the expected hash, that proves the integrity of the file. But it doesn't say anything about the file's authenticity: anybody could have made the file.
When there is authentication, nobody except the sender can change the message after MAC or signature is added.
This is almost right, but there are two gaps. First, nobody except the sender — but what about the sender? With asymmetric signatures, HMAC and KMAC, even if you know the private/secret key, it's impossible to produce two messages with the same signature/MAC. But with some other MAC algorithms, notably CMAC, if you know the key, it's easy to produce different messages that have the same MAC. This is also true with tags in typical AEAD constructions such as GCM, CCM and Poly1305.
Furthermore, if all you know is that the signature/MAC/tag is authentic, that does not guarantee that the message's integrity has been preserved. An adversary (who does not know the key) can swap signed messages around. For example, suppose Alice receives messages from Bob over a secure channel, and each message is protected by a MAC. This guarantees the authenticity of the messages, but not their integrity: an adversary who can intercept messages can remove or duplicate a message, and can reorder the messages. To guarantee the integrity of the communication, you need more, such as including a number in each message (if the successor of message n isn't message n+1, a message has been lost) and a terminator indication (if the last message received doesn't have the terminator, a message has been lost).
