The OCB mode of authenticated encryption (used for example with AES) is the fastest way to provide authenticity and confidentiality without having to strive into questions like: Encrypt then MAC, MAC then encrypt, Encrypt and MAC.
So why it is not widely used and didn't become a standard?
Because OCB is patented.
And there are other good solutions for authenticated encryption that aren't patented. This makes them more suitable, in most situations. I can recommend, e.g., EAX, GCM, or CWC. EAX and GCM have been used in some standards, and AES-GCM has been standardized.
For pointers where you can learn more, read Wikipedia. And try using search on this site with the phrase "authenticated encryption".
Update: There are now free licenses available for OCB. However, they have some unusual restrictions, which some implementors have expressed concerns over (e.g., one license only applies to open-source software; another allows only non-military uses). For a detailed discussion, see the responses on this thread on the IRTF CFRG mailing list.
As D.W. mentioned, the patent on OCB really is a killer; who would want to go through the legal hassle and expense of licensing OCB, when there are free authenticated encrypted modes available.
Another, considerably more minor issue, is that OCB does not support 'Additional Authenticated Data'. This is data that both the encryptor and decryptor provide to the mode; it is used to compute the authentication tag (along with the actual encrypted message). What this allows you to do is cryptographically bind the message to the message context; not only does the receiver verify that the message was not modified, he can also verify that someone didn't cut/paste a message that was originally meant in a different context.
You don't always need that; however, if you do need it, the only way to make it work with OCB is the put a copy of the context in the plaintext (and have the receiver verify that the context in the message is, in fact, the context that he expects). This is workable, but it would be cleaner if the mode supported it directly.
Update: the newer versions of OCB support associated data natively, but the patent situation remains "messy" at least
These are the shortcomings of OCB when one puts AES as the underlying block cipher- discussed in this presentation by Bernstein, Lange.
First there's suboptimal performance of AES-OCB3 (earlier authenticated ciphers such as Phelix (although broken in the nonce-reuse scenario) already beat AES-OCB3). Next AES-OCB3 is provably secure given that AES secure, but due to recent attacks on AES, it's not necessarily the case anymore. As for the security proof of AES-OCB3, it allows attack probability of $6q^2/2^{128}$, where $q$ is the number of AES block inputs: if $q$ is around $2^{60}$ the bound is far from ok. When it comes to side-channel attacks, it's not the strong point of AES and thus not for AES-OCB3. Finally, it's unclear how the OCB deals when flooding with forgeries (GCM allows discarding without decryption).
These are also some of the arguments that lead to the CAESAR authenticated cipher competition.
The "OpenSSL" license for OCB allows unrestricted use of OCB mode in any work "containing or based upon" OpenSSL. Only works "unrelated to" OpenSSL are excluded. No military nor embedded exclusion, no restriction on binary-only distribution, nothing: just start with or include anything from OpenSSL and you're golden. It is, though a patent rather than a copyright license, ultimately far less restrictive about what you may do with the licensed material than the GPL and arguably even freer than the 2-clause BSD license.
Given that it is hard to see what objection anyone might have to OCB on licensing terms at this point save, perhaps, a religious one.
