FreeIPA doesn't have any control over the packages shipped with Oracle Linux but as a general recommendation, you should avoid installing python packages with pip but rather rely on the ones provided by your OS distribution.
On RHEL 8.6, the project has been tested with python3-cryptography 3.2.1 and openssl 1.1.1k.

The one which is used in the standard install of RedHat or CentOS which is also OracleLinux is cryptography-38.0.1 To my surprise FreeIPA doesn't seem to have an virtual environment and take care of its used python modules, but uses the one from the operating system. I found this out by downgrading the system wide used python modules with pip. Since python3-cryptography 3.3.1 from the ol8_developer_EPEL does have the problem, the pip downgrade is needed. I would be surprised if Oracle would make an EPEL clone with a newer version of python-cryptography than RedHat.

FreeIPA is a system-wide service. It coordinates work of multiple components. Its management interface uses system-wide python packages. Your assumption that you can mix and match other components at will on IPA servers is incorrect. This applies not only to Python packages but also to other components: libraries and versions of other involved applications.

I totally agree you should not mix and match other components at will on IPA servers. Our Server is FreeIPA only. But there simply is no web GUI in FreeIPA at the moment if you use a standard install. You have to manually downgrade one python module to get FreeIPA working. Every day, because the auto update reverts the downgrade.
Please fix FreeIPA to work with its Python modules. I would guess the new version of python3-cryptography is not only in EPEL on Oracle Linux 8 servers, but also on RedHat 8 or 9 and on Fedora, so this should be a Problem affecting FreeIPA at the moment.
This can be done by changing the web GUI to work with recent versions of python3-cryptography, or by switching from using system wide use Python to shipping an own (older) version with FreeIPA. Your choice.

I am not sure where your problem lies but it is certainly not in FreeIPA upstream. If your OS vendor cannot maintain coherent packages, please work with them through the proper bug reporting channels for that vendor. As mentioned already, this problem is not seen on a default install of RHEL 8 at all, or any other distributions where FreeIPA development team has any chance to influence the packages.

FYI, FreeIPA upstream maintains two branches for releases that target specific RHEL and Fedora releases:
- ipa-4-9 is for RHEL 8 and Fedora 35
- ipa-4-10 is for RHEL 9 and Fedora 36+

RHEL team also maintains their own RHEL 7 packages as ipa-4-6 branch is not developed by FreeIPA upstream anymore.

In each case corresponding branches do handle what is available in the specific distribution. python-cryptography 35 is supported in Fedora 35 and is working with ipa-4-9. Python-cryptography 36-37 are used in Fedora 36+ (Rawhide uses python-cryptography 37), FreeIPA from ipa-4-10 works with all of them.

python-cryptography 38 is supported by unreleased version of FreeIPA through https://github.com/freeipa/freeipa/pull/6455 and other PRs. When we'd release next 4.9 and 4.10 versions, they'll have support for that version. If distributions aren't coordinating their packaging work, well, file bugs there, not here.

I am closing this bug report as a duplicate of https://pagure.io/freeipa/issue/9160