About Connecting to an Autonomous Database Instance

After you create database users, applications and tools connect to Autonomous Databases using Oracle Net Services (also known as SQL*Net). Oracle Net Services enables a network session from a client application to an Oracle Database server.

When a network session is established, Oracle Net Services acts as the data courier for both the client application and the database. It is responsible for establishing and maintaining the connection between the client application and the database, as well as exchanging messages between them.

Oracle Net Services supports a variety of connection types to connect to an Autonomous Database instance, including:

• JDBC Thin Driver: for Java applications, the JDBC Thin Driver is a pure Java driver. Many applications, including Oracle SQL Developer support JDBC Thin Driver connections.

• JDBC OCI: which is used by Java language applications. JDBC OCI adds a layer over Oracle Call Interface for Java applications. The Oracle SQLcl command-line interface uses JDBC OCI.

• Oracle Call Interface (OCI): used by many applications written in C language. Examples that use Oracle Call Interface include Oracle utilities such as Oracle SQL*Plus, SQL*Loader, and Oracle Data Pump.

• ODBC Drivers: used by applications running on Microsoft Windows, that are layered over Oracle Call Interface (OCI).

Third-party products and custom applications may use any of these connection types.

• Secure Connections to Autonomous Database
  Connections to Autonomous Database are made either over the public Internet, optionally with Access Control Rules (ACLs) defined, or using a private endpoint inside a Virtual Cloud Network (VCN) in your tenancy. When you specify a private endpoint configuration, this only allows traffic from the virtual cloud network you specify and blocks access to the database from all public IPs or VCNs. Configuring a private endpoint allows you to keep all traffic to and from your database off of the public internet.
• Connect to Autonomous Database Through a Firewall
  Most organizations protect networks and devices on a network using a firewall.  A firewall controls incoming and outgoing network traffic using rules which allow the use of certain ports and access to certain computers (or, more specifically IP addresses or host names).  An important function of a firewall is to provide separation between internal networks and the public internet.
• Using Application Continuity
  Application Continuity masks outages from end users and applications by recovering the in-flight work for impacted database sessions following outages. Application Continuity performs this recovery beneath the application so that the outage appears to the application as a slightly delayed execution.

Secure Connections to Autonomous Database

Connections to Autonomous Database are made either over the public Internet, optionally with Access Control Rules (ACLs) defined, or using a private endpoint inside a Virtual Cloud Network (VCN) in your tenancy. When you specify a private endpoint configuration, this only allows traffic from the virtual cloud network you specify and blocks access to the database from all public IPs or VCNs. Configuring a private endpoint allows you to keep all traffic to and from your database off of the public internet.

Many applications provide support for more than one connection type, but each type of connection to Autonomous Database uses certificate authentication and TCPS (Secure TCP) database connection using standard TLS 1.2. This ensures that there is no unauthorized access to the Autonomous Database and that communications between the client and server are fully encrypted and cannot be intercepted or altered.

Autonomous Database by default supports Mutual TLS (mTLS) connections. You have the option to configure an Autonomous Database instance to support both mTLS and TLS connections.

There are advantages for clients using TLS authentication with Autonomous Database, including the following:

• TLS connections do not require that you download a wallet. For TLS connections using JDBC Thin Driver with JDK8 or higher, a wallet is not required. This includes connections coming from the clients such as SQL Developer and SQL Command Line (SQLcl).

• Clients connecting with TLS do not need to worry about wallet rotation. Wallet rotation is a regular procedure for mTLS connections.

• TLS connections can be faster (providing less connection latency). TLS authentication can provide reduced connection latency compared to mTLS.

• TLS and mTLS connections are not mutually exclusive. Mutual TLS (mTLS) authentication is enabled by default and always available. When you enable TLS authentication, you can use either mTLS or TLS authentication.

• Using TLS authentication does not compromise the fully encrypted end-to-end communication between a client and Autonomous Database.

• About Mutual TLS (mTLS) Authentication
  Using Mutual Transport Layer Security (mTLS), clients connect through a TCPS (Secure TCP) database connection using standard TLS 1.2 with a trusted client certificate authority (CA) certificate. With mutual authentication both the client application and Autonomous Database authenticate each other. Autonomous Database uses mTLS authentication by default.
• About TLS Authentication
  Using Transport Layer Security (TLS), clients connect through a TCPS (Secure TCP) database connection using standard TLS 1.2. A client uses its list of trusted Certificate Authorities (CA)s to validate the server’s CA root certificate. If the issuing CA is trusted, the client verifies that the certificate is authentic. This allows the client and Autonomous Database to establish the encrypted connection before exchanging any messages.

About Mutual TLS (mTLS) Authentication

Using Mutual Transport Layer Security (mTLS), clients connect through a TCPS (Secure TCP) database connection using standard TLS 1.2 with a trusted client certificate authority (CA) certificate. With mutual authentication both the client application and Autonomous Database authenticate each other. Autonomous Database uses mTLS authentication by default.

Mutual TLS authentication requires that the client downloads or obtains a trusted client CA certificate for connecting to an Autonomous Database instance. Autonomous Database then uses the certificate to authenticate the client. This provides increased security and specifies the clients that can communicate with an Autonomous Database instance.

Certification authentication with Mutual TLS uses an encrypted key stored in a wallet on both the client (where the application is running) and the server (where your database service on the Autonomous Database is running). The key on the client must match the key on the server to make a connection. A wallet contains a collection of files, including the key and other information needed to connect to your Autonomous Database instance. All communications between the client and the server are encrypted.

To secure the connection to your Autonomous Database instance a service administrator downloads the client credentials (wallet files) from Autonomous Database. If you are not an Autonomous Database service administrator, your administrator provides you with the client credentials. See Download Client Credentials (Wallets) for more information.

The following figure shows client secure connections to Oracle Autonomous Database over the public Internet using Mutual TLS connections. If you configure your database to use private endpoints, then the public internet is not used and the connection uses a private endpoint inside a Virtual Cloud Network (VCN) in your tenancy.

Description of the illustration autonomous-database.eps

About TLS Authentication

Using Transport Layer Security (TLS), clients connect through a TCPS (Secure TCP) database connection using standard TLS 1.2. A client uses its list of trusted Certificate Authorities (CA)s to validate the server’s CA root certificate. If the issuing CA is trusted, the client verifies that the certificate is authentic. This allows the client and Autonomous Database to establish the encrypted connection before exchanging any messages.

When you connect with TLS authentication using JDBC Thin Driver clients, including Oracle SQL Developer and Oracle SQLcl, you do not need to download a wallet to secure the connection to your Autonomous Database instance. TLS authentication enables the client to verify the identity of the Autonomous Database service to provide secure communication.

Depending on the type of client, a TLS connection has the following support with Autonomous Database:

• For connections with JDBC Thin Driver using JDK8u162 or higher, including connections with Oracle SQL Developer and Oracle SQLcl, a wallet is not required.

• Oracle Call Interface (OCI) clients support TLS authentication without a wallet if you are using the following client versions:

  • Oracle Instant Client/Oracle Database Client 19.13 - only on Linux x64

  • Oracle Instant Client/Oracle Database Client 19.14 (or later) and 21.5 (or later) - only on Linux x64 and Windows

• If the client is connecting with managed ODP.NET or ODP.NET Core versions 19.13 or 21.4 (or above) using TLS authentication, the client can connect without providing a wallet.

There are network access prerequisites for TLS connections. See Network Access Prerequisites for TLS Connections for more information.

Connect to Autonomous Database Through a Firewall

Most organizations protect networks and devices on a network using a firewall.  A firewall controls incoming and outgoing network traffic using rules which allow the use of certain ports and access to certain computers (or, more specifically IP addresses or host names).  An important function of a firewall is to provide separation between internal networks and the public internet.

When Autonomous Database is configured for access using the public internet, you must configure the firewall to allow access to Autonomous Database servers.

To access the Autonomous Database from behind a firewall, the firewall must permit the use of the port specified in the database connection when connecting to the servers in the connection. The default port number for Autonomous Database mTLS connections is 1522 (find the port number in the connection string from the tnsnames.ora file in your credentials ZIP file). For example, see the port value in the following tnsnames.ora file:

db2022adb_high = (description = ( 
                address=(protocol=tcps)
                (port=1522)
                (host=adb.example.oraclecloud.com))
                (connect_data=(service_name=example_high.adb.oraclecloud.com))
                (security=(ssl_server_dn_match=yes)))

Your firewall must allow access to servers within the .oraclecloud.com domain using port 1522. To connect to Autonomous Database, depending upon your organization's network configuration, you may need to use a proxy server to access this port or you may need to request that your network administrator open this port.

Using Application Continuity

Application Continuity masks outages from end users and applications by recovering the in-flight work for impacted database sessions following outages. Application Continuity performs this recovery beneath the application so that the outage appears to the application as a slightly delayed execution.

Note:

By default Application Continuity is disabled.

See Use Application Continuity on Autonomous Database for more information on Application Continuity.