You are describing AES-OFB: AES OFB mode. AES-OFB is a fine building block. But it alone isn't enough. It only provides confidentiality, and does not provide integrity.
Some textbooks will tell you that AES-OFB is fine if you only need confidentiality, but they're taking too narrow a view. In practice, we have learned that it's not fine. In practice, you essentially always need both confidentiality and integrity, even if you think you only need confidentiality.
If you try to use something that only provides confidentiality but not integrity (such as AES-OFB alone), often you'll end up with something that is vulnerable to subtle chosen-ciphertext attacks: e.g., reaction attacks, padding oracle attacks (typically not a risk for AES-OFB, but who knows), gzip format oracle attacks, or any of a number of other failure modes. As Moxie Marlinspike explains in his Cryptographic Doom Principle, "if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom". It's too hard to anticipate all of the possible subtle chosen-ciphertext attacks that might be possible. You're not smart enough to build a system using only encryption with integrity. It's not worth the risk.
Instead, good cryptographic engineering practice is to always pick something that provides both confidentiality and integrity. For instance, you can combine AES-CBC (or AES-CTR, or AES-OFB) with message authentication (e.g., SHA256-HMAC) using Encrypt-then-MAC. Or, you can use authenticated encryption, i.e., a dedicated mode that provides both, e.g., AES-GCM-SIV or XChaCha20-Poly1305.
Lastly, let me warn that AES-OFB mode has some implementation hazards. If you ever repeat an IV, then it fails catastrophically. In other words, it is a little bit "brittle" to certain kinds of implementation errors. For this reason, some practitioners recommend using modes that are less brittle, such as nonce-misuse resistant modes like AES-GCM-SIV.
To learn more about this broad subject, see https://security.stackexchange.com/a/2206/971.