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.
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.
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. With a private endpoint, when public access is
enabled with Allow public access, the instance has both a private
endpoint and a public endpoint:
The private hostname, endpoint URL, and private IP address allow you
to connect to the database from the VCN where the database resides.
The public hostname allows you to connect to the database from
specific public IP addresses or from specific VCNs if those VCNs are configured
to privately connect to Autonomous Database using a Service Gateway.
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 (use port 1522 to connect with mTLS). You have
the option to configure an Autonomous Database
instance to support both mTLS and TLS connections (use port 1521 to connect with
TLS).
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.
Topics
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.
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.
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. Use port 1522 to
connect to an Autonomous Database
instance with mTLS (the 1522 port assignment cannot be changed).
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.
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. Use port 1521 to
connect to an Autonomous Database instance
with TLS (the 1521 port assignment cannot be changed).
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.
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. Use port 1522 for
Autonomous Database mTLS connections (you
can see 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:
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.
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.