1. Security Guide
  2. Changes in This Release for Oracle Database Security Guide

Changes in This Release for Oracle Database Security Guide

This preface contains:

Changes in Oracle Database Security 23ai

Oracle Database Security Guide for Oracle Database 23ai has new security features.

Parent topic: Changes in This Release for Oracle Database Security Guide

Transport Layer Security 1.3 Protocol Now Supported in Oracle Database

Starting with Oracle Database 23ai, Oracle Database supports Transport Layer Security (TLS) version 1.3, which affects the use of cipher suites in TLS settings.

Because TLS 1.3 handles initial session setup more efficiently than earlier TLS versions, users moving to TLS 1.3 will see improvements in TLS performance. TLS 1.3 also implements newer, more secure cipher suites that improve confidentiality of data in transit. Oracle recommends that you move immediately from the desupport TLS protocol versions (1.0 and 1.1) to version 1.3. Version 1.2 is still supported.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Simplified Transport Layer Security Configuration

Starting with Oracle Database 23ai, the Transport Layer Security (TLS) configuration between the database client and server has been simplified yet made more secure.

The changes are as follows:

  • Update to the default for the client WALLET_LOCATION parameter so that if it is not set, then the value of the TNS_ADMIN parameter is used instead.
  • Update to the SSL_VERSION parameter so that it can accept a comma-separated list of strings such as (TLSv1.3, TLSv1.2).
  • Introduction of the ALLOWED_WEAK_CERT_ALGORITHMS parameter for users whose environments still require the use of the earlier certificate signature algorithms. This parameter replaces the ALLOW_MD5_CERTS and ALLOW_SHA1_CERTS parameters. If ALLOWED_WEAK_CERT_ALGORITHMS is set, then Oracle Database ignores ALLOW_MD5_CERTS and ALLOW_SHA1_CERTS. However, if ALLOWED_WEAK_CERT_ALGORITHMS is not set, then Oracle Database checks and uses the ALLOW_MD5_CERTS and ALLOW_SHA1_CERTS settings. By default, SHA1 certificate are allowed and MD5 certificates are disallowed.
  • Deprecation of the following parameters:
    • ADD_SSLV3_TO_DEFAULT
    • ALLOW_MD5_CERTS
    • ALLOW_SHA1_CERTS
  • Modifications to how wallets are loaded
    • Server-side wallets: The WALLET_LOCATION parameter for server-side wallets is deprecated. Instead, use the WALLET_ROOT initialization parameter in the init.ora file.
    • Client-side wallets: The WALLET_LOCATION parameter can still be used for client-side wallets.
  • Improved performance for the processing of wallets
  • For users to enable TLS between the database client and the server, the only required and minimum configuration is putting a pair of wallets in client side TNS_ADMIN directory, and server side WALLET_ROOT directory.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Schema Privileges to Simplify Access Control

Starting with Oracle Database 23ai, Oracle Database supports schema privileges in addition to the existing object, system, and administrative privileges.

The following new system privileges are required if you plan to manage the security policies for row level security, fine-grained auditing, or Oracle Data Redaction. They can be granted to enable the security policy across all non-SYS schemas in the database or to restrict the security policy to one schema.

  • ADMINISTER ROW LEVEL SECURITY POLICY, for when the DBMS_RLS package is used for row level security policies
  • ADMINISTER FINE GRAINED AUDIT POLICY, for when the DBMS_FGA package is used for fine-grained audit policies
  • ADMINISTER REDACT POLICY, for when the DBMS_REDACT package is used for data redaction policies

As part of this new feature, the following views are introduced:

  • DBA_SCHEMA_PRIVS
  • ROLE_SCHEMA_PRIVS
  • USER_SCHEMA_PRIVS
  • SESSION_SCHEMA_PRIVS
  • V$ENABLEDSCHEMAPRIVS

In previous releases, object privileges provided fine-grained control over access to individual objects, such as the HR.EMPLOYEES table. System privileges were designed for administrators to grant similar access to all objects in the database of a certain type (for example, the SELECT ANY TABLE system privilege). For applications that only need to provide enough privileges (least privilege principle) for users to application objects, every privilege for every object had to granted and tracked. Hence, new objects in the same schema required new object privileges. With the new schema privileges, you can grant a privilege for the entire schema, thereby simplifying application authorizations and improving security. For example: 

GRANT SELECT ANY TABLE ON SCHEMA HR TO SCOTT;

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Oracle SQL Firewall Included in Oracle Database

Starting with Oracle Database 23ai, Oracle SQL Firewall inspects all incoming SQL statements and ensures that only explicitly authorized SQL is run.

You can use SQL Firewall to control which SQL statements are allowed to be processed by the database. You can restrict connection paths associated with database connections and SQL statements. Unauthorized SQL can be logged and blocked.

Because SQL Firewall is included in the Oracle database, it cannot be bypassed. All SQL statements are inspected, whether local or network, or encrypted or clear text. It examines top-level SQL, stored procedures and the related database objects.

SQL Firewall provides real-time protection against common database attacks by restricting database access to only authorized SQL statements or connections. It mitigates risks from SQL injection attacks, anomalous access, and credential theft or abuse.

SQL Firewall uses session context data such as IP address, operating system user name, and operating system program name to restrict how a database account can connect to the database. This helps mitigate the risk of stolen or misused application service account credentials. A typical use case for SQL Firewall is for application workloads.

You can use SQL Firewall in both the root and a pluggable database (PDB).

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Increased Maximum Password Length

Starting with Oracle Database 23ai, Oracle Database supports passwords up to 1024 bytes in length.

In previous releases, the Oracle Database password length and the secure role password length could be up to 30 bytes. The increased maximum password length to 1024 bytes provides the following benefits:

  • It accommodates passwords that are used by Oracle Identity Cloud Service (IDCS) and Identity Access Management (IAM). The increase to 1024 bytes enables uniform password rules for all Cloud deployments.
  • The 30-byte limitation was too restrictive when password multi-byte characters used more than 1 byte in an NLS configuration.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Read-Only Users and Sessions

Starting with Oracle Database 23ai, you can control whether a user or session is enabled for read-write operations, irrespective of the privileges of the user that is connected to the database.

The READ_ONLY session applies to any type of user for any type of container. The READ_ONLY user only applies to local users.

Providing the capability to disable and re-enable the read-write capabilities of any user or session without revoking and re-granting privileges provides you with more flexibility to temporarily control the privileges of users or sessions for testing, administration, or application development purposes. It also gives you a simple way to control the read-write behavior within different parts of an application that are used by the same user or session.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

New Database Role for Application Developers

Starting with Oracle Database 23ai, a new role specifically for application developers, DB_DEVELOPER_ROLE, is introduced for stronger security using the least privilege principle.

Oracle Database has many distinct privileges that can be granted to schema users or roles, as well as numerous stored or built-in PL/SQL packages that can be executed. Developers who design, develop, and deploy an application need a subset of these. Because an application developer or owner may not know or understand all the privileges that are needed by application developers, this could potentially result in database administrators granting all-encompassing privileges to developers. Providing developers with more privileges than necessary could pose a potential security risk. An alternative to granting all-encompassing privileges is to selectively grant privileges on demand as the application developer identifies the privileges they require that are not currently granted.

The benefit of the DB_DEVELOPER_ROLE role is that it quickly and easily provides the application developer with only the privileges that they need to design, implement, and deploy applications on Oracle databases.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Oracle Data Dictionary Protection Extended to Non-SYS Oracle Schemas with Separation of Duties Protection

Starting with Oracle Database 23ai, Oracle Database schemas now can have data dictionary protection with additional separation of duties protection for the SYSBACKUP, SYSKM, SYSRAC, and SYSDG schemas.

Dictionary protection has been applied to Oracle schemas such as AUDSYS and LBACSYS. For the full list of dictionary protected Oracle schemas, run the following query: 

SELECT USERNAME, DICTIONARY_PROTECTED FROM DBA_USERS WHERE DICTIONARY_PROTECTED='YES';

The dictionary protection includes the underlying schemas for the SYSDBA, SYSBACKUP, SYSKM, SYSRAC, and SYSDG administrative privileges. These have additional separation of duties protections. Direct and proxy logins are blocked and password changes are restricted to the user only.

Oracle schemas provide critical functionality for Oracle Database features. By enabling these schemas to have dictionary protection, you can prevent inadvertent and malicious changes within these schemas that could endanger Oracle Database functionality.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Strict DN Matching with Both Listener and Server Certificates

Starting with Oracle Database release 23ai, the behavior of the SSL_SERVER_DN_MATCH parameter has changed.

Previously, Oracle Database performed the DN check only with the database server certificate, and both the HOSTNAME and the SERVICE_NAME setting in the connect string could be used for a partial DN match.

With Oracle Database 23ai, Oracle Database checks both the listener and server certificates. In addition, the SERVICE_NAME setting in the connect string is not used to check during a partial DN match. The HOSTNAME setting can still be used for partial DN matching with the certificate DN and subject alternative name (SAN), on both the listener and server certificates.

When set to TRUE, the SSL_ALLOW_WEAK_DN_MATCH parameter reverts SSL_SERVER_DN_MATCH to the behavior earler than release 23ai and enables DN matching to only check the database server certificate (but not the listener) and enable the service name to be used for partial DN matching.

DN matching with both the listener and server certificates provides better security to ensure that the client is connecting to the correct database server. The service name setting is also removed from SSL_SERVER_DN_MATCH for better security and partial DN matching can still be performed with the HOSTNAME connect string parameter with the certificate DN and subject alternative name (SAN) matching.

The SSL_ALLOW_WEAK_DN_MATCH, though new to this release, is marked as deprecated because it is a temporary mechanism to enable interoperability with releases prior to 23ai.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Ability to Configure Transport Layer Security Connections without Client Wallets

Starting with Oracle Database 23ai, for Linux, non-Linux, and Microsoft Windows platforms, an Oracle Database client is no longer required to provide a wallet to hold well-known CA root certificates if they are available in the local system.

The Oracle Database wallet search order determines the location (Windows (Microsoft Certificate Store) or Linux) of these certificates in the local system.

Transport Layer Security (TLS) requires either one-way authentication or two-way authentication. In one-way TLS authentication, which is commonly used for HTTPS connections, you will no longer need to install and configure a client wallet to hold the server's CA certificate as long as it is already available in the local system. If the server's CA certificate is not installed in the local systems, then client wallet is still required.

This enhancement greatly simplifies the Oracle Database client installation and the use of TLS protocol to encrypt Oracle Database client-server communications.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Updated Kerberos Library and Other Improvements

Starting with Oracle Database 23ai, Oracle Database supports MIT Kerberos library version 1.21.2, and provides cross-domain support for accessing resources in other domains.

This Kerberos enhancement improves security and allows Kerberos to be used in more Oracle Database environments.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Improved and More Secure Local Auto-Login Wallets

Starting with Oracle Database 23ai, newly created local auto-login wallets (or pre-release 23ai wallets that have been updated for release 23ai) are more secure.

A local auto-login wallet is now more tightly bound to the host where it was created or modified. The local auto-login process is also more secure, does not require additional deployment requirements, and does not require root access.

Local auto-login wallets are more secure now and support both bare metal and virtual environments.

This enhancement also applies to Tranparent Data Encryption (TDE) local auto-login keystores.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

New sqlnet.ora Parameter to Prevent the Use of Deprecated Ciphers

Starting with Oracle Database 23ai, you can block the use of deprecated ciphers by setting the SSL_ENABLE_WEAK_CIPHERS sqlnet.ora parameter to FALSE.

You can prevent the use of deprecated ciphers, which are less secure than the latest ciphers, in an Oracle database if you do not have a dependency on them. This simplifies the passing of compliance audits and improves the overall security of your database.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Enhancements to RADIUS Configuration

Starting with Oracle Database 23ai, Oracle Database supports the Requests for Comments (RFC) 6613 and 6614 guidelines, and updates to RADIUS security with the latest standards.

This enhancement introduces the following new RADIUS-related sqlnet.ora parameters:

  • SQLNET.RADIUS_ALTERNATE_TLS_HOST
  • SQLNET.RADIUS_ALTERNATE_TLS_PORT
  • SQLNET.RADIUS_AUTHENTICATION_TLS_HOST
  • SQLNET.RADIUS_AUTHENTICATION_TLS_PORT
  • SQLNET.RADIUS_TRANSPORT_PROTOCOL

The following existing RADIUS sqlnet.ora parameters have been updated:

  • SQLNET.RADIUS_ALTERNATE_PORT
  • SQLNET.RADIUS_AUTHENTICATION_PORT
  • SQLNET.RADIUS_SECRET

The older RADIUS standards are blocked by default in Oracle Database 23ai. If you need to enable pre-release 23ai clients to connect using the older protocol, then set one or both of the following parameters, new to release 23ai, in the sqlnet.ora file.

  • SQLNET.RADIUS_ALLOW_WEAK_CLIENTS enables pre-release 23ai database clients to connect RADIUS users using the older standard.
  • SQLNET.RADIUS_ALLOW_WEAK_PROTOCOL enables the pre-release 23ai database server to connect to the RADIUS server using the older standard.

This enhancement is beneficial in that Oracle Database RADIUS API implements TCP over Transport Layer Security (TLS) and provides other security improvements, such as support for AES256 and SHA512.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Enhancements to the DBMS_CRYPTO PL/SQL Package

Starting with Oracle Database 23ai, the DBMS_CRYPTO PL/SQL package has APIs to support several customer needs, such as elliptic-curve Diffie–Hellman (ECDH) operations, updated signature and verification algorithms, and other enhancements.

These enhancements are as follows:

  • New APIs for elliptic-curve Diffie–Hellman (ECDH) operations
    • ECDH_GENKEYPAIR: This function generates an EC public/private key pair
    • ECDHDERIVE_SHAREDSECRET: This function derives shared secret using private key of local application and public key from the remote application.
  • New PKENCRYPT/PKDECRYPT algorithm: PKENCRYPT_RSA_PKCS1_OAEP_SHA2
  • New chain modes GCM, CCM, and XTS
  • New DBMS_CRYPTO block cipher suites AES_CCM_NONE and AES_GCM_NONE
  • New signature and verification algorithms:
    • SIGN_SHA224_ECDSA
    • SIGN_SHA256_ECDSA
    • SIGN_SHA384_ECDSA
    • SIGN_SHA512_ECDSA
    • SIGN_ECDSA

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Authenticating and Authorizing IAM Users to Oracle Autonomous Database on Dedicated Exadata Infrastructure

Starting with Oracle Database 23ai, users can authenticate and authorize IAM users to Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Additional enhancements are as follows:

  • Applications can now connect to an Autonomous Database instance by using end-user, instance, and resource principals.
  • IAM users can now proxy to an Autonomous Database by using a database user schema.
  • Database links are supported for IAM connections.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Ability of Azure Users to Log in to Oracle Database with Their Azure AD OAAuth2 Access Token

Available initially for the Oracle Autonomous Database in June 2022, Microsoft Azure Active Directory (Azure AD) users can now log in to Oracle Databases on-premises and in the cloud.

You can use Azure AD OAuth2 tokens to access the database. Azure AD users can access the database directly using their Azure AD token, and applications can use their service tokens to access the database.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Ability to Audit Object Actions at the Column Level for Tables and Views

Starting with Oracle Database 23ai, you can create unified audit policies to audit individual columns in tables and views.

The ACTIONS clause of the CREATE AUDIT POLICY and ALTER AUDIT POLICY procedures allows you to specify the list of columns whose access is to be audited. For example, to audit UPDATE statements on the SALARY column of a table, you would specify ACTIONS UPDATE(SALARY).

The feature enables you to configure more granular and focused audit policies, and ensures that auditing is selective enough to reduce the creation of unnecessary audit records, and effective enough to let you meet your compliance requirements.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Consolidation of the FIPS_140 Parameter

Starting with Oracle Database 23ai, you can use the FIPS_140 parameter to configure FIPS in a uniform way with multiple Oracle Database environments and features.

These environments and features are as follows:

  • Transparent Data Encryption (TDE)
  • DBMS_CRYPTO PL/SQL package
  • Transport Layer Security (TLS)
  • Network native encryption

You can still use the legacy FIPS 140-2 configurations for these environments, but Oracle recommends that you use the consolidated FIPS_140 parameter instead.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Desupport of Case Insensitive Passwords

Starting with Oracle Database 23ai, case-insensitive passwords are no longer supported.

Users whose passwords are case-insensitive will be unable to log in to the database after upgrading to Oracle Database 23ai. Before upgrading, an administrator must use the following query to find the users whose passwords are case-insensitive and notify these users to change their passwords: 

SELECT USERNAME FROM DBA_USERS
WHERE (PASSWORD_VERSIONS = '10G '
OR PASSWORD_VERSIONS = '10G HTTP ')
AND USERNAME <> 'ANONYMOUS';

Changing the password enables the use of later, more secure password versions. If you have already upgraded to release 23ai and still have users whose passwords are case insensitive, then these users will not be able to log in. An administrator will need to change the password for these users. The password of any user that has only the 10G password version remains case insensitive until it is changed, and it becomes case sensitive after it is changed.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Desupport of Traditional Auditing

Starting with Oracle Database 23ai, traditional auditing is desupported.

Unified auditing is the way forward to perform Oracle Database auditing. Unified auditing offers more flexibility to perform selective and effective auditing, which helps you focus on activities that really matter to your enterprise. Unified auditing has one single and secure unified trail, conditional policy for audit selectivity, and default predefined policies for simplicity. To improve security and compliance, Oracle strongly recommends that you use unified auditing.

Related Topics

Parent topic: Changes in Oracle Database Security 23ai

Updates to Oracle Database Security 23ai

Oracle Database Security Guide for Oracle Database 23ai has updates.

Parent topic: Changes in This Release for Oracle Database Security Guide

New Procedure for Oracle SQL Firewall DBMS_SQL_FIREWALL PL/SQL Package

The Oracle SQL Firewall package DBMS_SQL_FIREWALL now has an additional procedure, DBMS_SQL_FIREWALL.APPEND_ALLOW_LIST_SINGLE_SQL.

This procedure enables you to individually append specific SQL records from a capture log or a violation log to an existing allow-list. While DBMS_SQL_FIREWALL.APPEND_ALLOW_LIST provides the flexibility to append the entire violation or capture log to the allow-list, in most common scenarios you might also need the flexibility to add just one of them instead of the entire list. In previous releases, if you wanted to append specific SQL commands to an allow-list, you had to use DBMS_SQL_FIREWALL.APPEND_ALLOW_LIST to append the entire violation or capture log to the allow-list, and then use DBMS_SQL_FIREWALL.DELETE_ALLOWED_LIST to manually delete the unwanted entries. This enhancement gives more flexibility to adjust the allow-list with specific records that you want to include.

Related Topics

Parent topic: Updates to Oracle Database Security 23ai

DBMS_CRYPTO Support for SM2, SM3, SM4, and SHA-3 Cryptographic Algorithms

The DBMS_CRYPTO PL/SQL package now supports the use of SM2, SM3, SM4, and SHA-3 cryptographic algorithms.

  • SM2 is an asymmetric cryptographic algorithm. It is deployed for digital signatures, key exchange, and encryption.
  • SM3 is a 256-bit hash algorithm. It is used for digital signatures, message authentication codes, and pseudorandom number generators.
  • SM4 is a block symmetric encryption algorithm.
  • SHA-3 (Secure Hash Algorithm 3) is a new cryptographic hash algorithm that supports fixed length hash, variable length hash, sign, verify, Hash-based Message Authentication Code (HMAC), and KECCAK Message Authentication Code (KMAC) functionalities.

The following DBMS_CRYPTO functions have been enhanced to support to the new algorithm constants:

  • DBMS_CRYPTO.ENCRYPT
  • DBMS_CRYPTO.DECRYPT
  • DBMS_CRYPTO.HASH
  • DBMS_CRYPTO.MAC
  • DBMS_CRYPTO.PKENCRYPT
  • DBMS_CRYPTO.PKDECRYPT
  • DBMS_CRYPTO.SIGN
  • DBMS_CRYPTO.VERIFY

The following DBMS_CRYPTO functions have been added to support to the new algorithm constants for some SHA-3 features:

  • DBMS_CRYPTO.HASH_LEN (similar to the existing DBMS_CRYPTO.HASH function but it includes an extra input length)
  • DBMS_CRYPTO.KMACXOF (similar to the existing DBMS_CRYPTO.MAC function but it includes an extra input length and custom string)

This new hash type can be used with DBMS_CRYPTO.ENCRYPT and DBMS_CRYPTO.DECRYPT:

  • ENCRYPT_SM4

These new hash types can be used with DBMS_CRYPTO.HASH:

  • HASH_SHA3_224
  • HASH_SHA3_256
  • HASH_SHA3_384
  • HASH_SHA3_512
  • HASH_SM3

These new MAC types can be used with the DBMS_CRYPTO.MAC function:

  • HMAC_SHA3_224
  • HMAC_SHA3_256
  • HMAC_SHA3_384
  • HMAC_SHA3_512

These new encryption types can be used with DBMS_CRYPTO.PKENCRYPT and DBMS_CRYPTO.PKDECRYPT:

  • PKENCRYPT_SM2
  • KEY_TYPE_SM2

These new algorithms can be used with DBMS_CRYPTO.SIGN and DBMS_CRYPTO.VERIFY:

  • SIGN_SHA3_224_RSA
  • SIGN_SHA3_256_RSA
  • SIGN_SHA3_384_RSA
  • SIGN_SHA3_512_RSA
  • SIGN_SHA3_224_ECDSA
  • SIGN_SHA3_256_ECDSA
  • SIGN_SHA3_384_ECDSA
  • SIGN_SHA3_512_ECDSA
  • SIGN_SM3_SM2

SHA-3 provides variable-length hash functions, allowing for hash values of any desired length.

These new variable length hash types can be used with the new DBMS_CRYPTO.HASH_LEN function:

  • HASH_SHAKE128
  • HASH_SHAKE256

These new variable length MAC types can be used with the new DBMS_CRYPTO.KMACXOF function:

  • KMACXOF_128
  • KMACXOF_256

Related Topics

Parent topic: Updates to Oracle Database Security 23ai

orapki Enhancements

The orapki command line utility has been enhanced to include mkstore features and new command parameters to specify wallet certificates and keys.

  • mkstore features included in orapki: mkstore features have been incorporated into the orapki command line utility to simplify the management of Oracle Database wallets, certificates, and secrets. The new commands in orapki support the following capabilities of mkstore:
    • The ability to create, modify and delete secret store credentials and entries
    • The ability to list specific secret store credentials and entries

    These capabilities are supported with the orapki secretstore command.

    The mkstore utility has been deprecated. Oracle recommends that you use orapki instead.

  • New command parameters to specify wallet certificates and keys: The orapkicommand-line utility now enables you to store alias names in an Oracle wallet and also display and reference certificate thumbprint signatures in an Oracle wallet. These enhancements enable users to do the following:
    • Specify these private keys using their thumbprint or alias in a connect string.
    • Use the thumbprint to specify a private key in the Microsoft Certificate Store (MCS).
    • Store certificates with their serial numbers to simplify specifying certificates or removing certificates.

    This enhancement affects the orapki wallet add, orapki wallet display, and orapki wallet remove commands. The benefit of this feature is the simplification of managing wallets and selecting certificates through the new thumbprint, alias, and serial number parameters.

Related Topics

Parent topic: Updates to Oracle Database Security 23ai

Microsoft Entra ID (Azure AD) Integration Enhancements

Oarcle Cloud Infrastructure (OCI) and Oracle Database Instant Client now can directly retrieve Microsoft Entra ID (Azure AD) OAuth2 tokens. In addition, the Oracle Database server on AIX, Solaris, and HPUX platforms support the Entra ID integration.

Microsoft has renamed Azure AD to Entra ID. This terminology will be used in Oracle Database 23ai and later releases.

  • OCI and Instant Client now can directly retrieve Entra ID OAuth2 tokens. Oracle Call Interface (OCI) and Oracle Database Instant Client can retrieve a Microsoft Entra ID OAuth2 token directly from Entra ID instead of relying on a separate script or process to retrieve the token first. This design improves the interactive flow between the database server and the client when users connect to the database (for example, with SQL*Plus). This enhancement simplifies the configuration that an end-user must perform in order to retrieve tokens. In previous releases, the end-user had to run a script to get the token from Entra ID before starting SQL*Plus or any other OCI utilities. Now, the token retrieval is part of OCI. This enhancement is similar to recent enhancements with the JDBC-thin and ODP.NET core and managed clients.

  • The Entra ID Integration is now supported with the Oracle Database server running on the AIX, Solaris, and HPUX platforms. Entra ID integration is now available for the Oracle Database server on all supported operating system platforms. In addition to the newly supported AIX, Solaris, and HPUX platforms, Linux and Windows are still supported. The Entra ID integration feature for the Oracle Database is supported on Windows and Linux only with the full (thick) client and the instant client.

Related Topics

Parent topic: Updates to Oracle Database Security 23ai