Connecting to Your Autonomous Database Has Never Been Easier

November 7, 2023 | 7 minute read
Can Tuzla
Principal Product Manager
Text Size 100%:
Update 11/07/2023: Autonomous Database Serverless (ADB-S) now supports creating database links between ADB-S instances via TLS. Check out the bonus content added below to find out how you can create database links between your ADB-S instances without a wallet.

Autonomous Database Serverless (ADB-S) users today have the option to deploy their instances on either public or private endpoints. Whether your connections are made over the public internet or through a Virtual Cloud Network (VCN), there is one thing in common… They are all secure and use the Transport Layer Security (TLSv1.2) protocol. In other words, any communication between the database and the client is encrypted and both the client and the database can authenticate each other. When it comes to authenticating the client and the server, there are a couple of options:

  • Both the client and the server authenticate each other (mutual TLS or mTLS)
  • Only the client authenticates server (one-way TLS or simply TLS)

ADB-S uses mutual TLS (mTLS) by default regardless of your network configuration, so both the client and the database verify each other’s certificates. To complete server-side authentication, any client connecting to an ADB-S instance must present their client credentials which can be downloaded as a zip file and contains the SSO wallet, keystore, truststore, and network configuration files. This pretty much sums up how mTLS works and why you need to download a wallet to connect to your Autonomous Database. mTLS sounds great, doesn’t it? You might be thinking “who needs TLS when there is mTLS” and the answer could be you! Before we dig any deeper, I’d like to announce that ADB-S now fully supports TLS authentication as well. ADB-S users can now enable TLS in addition to the mTLS authentication depending on their network configuration (we will come to the prerequisites in a second). So, what are the benefits of TLS authentication?

  • No wallet downloads required. For 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) as well. Similarly, Oracle Call Interface (OCI) clients with the following versions also support connections without a wallet:
              - 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) - all platforms
  • No wallet rotations required. Since there is no wallet needed for the clients mentioned above, there is no need to worry about a wallet rotation either.
  • Better connection latency. TLS authentication offers a reduced connection latency compared to mTLS.
  • TLS can coexist with mTLS. TLS and mTLS connections are not mutually exclusive. mTLS authentication is enabled by default and always there. When you enable TLS authentication, you can use either mTLS or TLS (i.e. it’s either mTLS-only or mTLS + TLS).

Not to mention, all these advantages of TLS authentication can be had without compromising the fully encrypted end-to-end communication between the client and the database and it’s just a single click away. Before we jump into a walkthrough example of TLS connections in ADB-S, let’s quickly take a look at the prerequisites of this new feature. You can use TLS authentication in ADB-S if your instance is on a:

  • Public endpoint with an Access Control List (ACL). At least one IP or VCN rule required.
  • Private endpoint

For the remainder of this blog post, we are going to focus on a simple demonstration in which we will create an ADB-S instance and connect to it via TLS authentication. Here are the steps that we will follow:

  • Configure an IP ACL and enable TLS authentication during provisioning
  • Obtain the TLS connect string
  • Connect to the ADB-S instance without using a wallet
  • Bonus content: Create a database link between two ADB-S instances

Configure an IP ACL and enable TLS authentication during provisioning

As you can see in the screenshot below, we now have a new checkbox in the “Choose network access” section to designate whether you want to require mTLS authentication for your connections or allow both TLS and mTLS. By default, mTLS authentication is required and only ways to enable TLS in addition to mTLS are either to define an ACL or to use private endpoint. For this demonstration, we are going to be defining an IP ACL and unchecking the mTLS requirement so that we can use TLS authentication as well.

If you decide to enable TLS authentication for an existing ADB-S instance that is on private endpoint or public endpoint with an ACL, you can do so by editing the mTLS requirement in the ADB-S details page as shown below:

Obtain the TLS connect string

Once our ADB-S instance is provisioned, all we need to do is to obtain our TLS connect string from the “Connection Strings” table which is located under “Database Connection” in the ADB-S details page. There are a couple of things to note in this table. Firstly, the table content (aka connect strings) changes depending on the option you select in the dropdown. If TLS is enabled, the dropdown will have two options, namely ‘TLS’ and ‘Mutual TLS’. Since we are interested in establishing a TLS connection, let’s select the TLS option in the dropdown and copy one of the connect strings as shown below:

Connect to the ADB-S instance without using a wallet

The next step is to connect to my ADB-S instance from my application via JDBC or from a client such as SQL Developer or SQLcl. For the sake of this demonstration, I will be using SQLcl to connect my ADB-S instance via TLS and most importantly I will not be downloading or dealing with any wallets.

ctuzla-mac:bin ctuzla$ pwd
ctuzla-mac:bin ctuzla$
ctuzla-mac:bin ctuzla$ ./sql ADMIN@'(description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1521)('

SQLcl: Release 20.2 Production on Tue Oct 05 13:39:09 2021

Copyright (c) 1982, 2021, Oracle.  All rights reserved.

Password? (**********?) ************

Last Successful login time: Tue Oct 05 2021 13:39:15 -07:00

Connected to:

Oracle Database 19c Enterprise Edition Release - Production


SQL> select * from dual;



It's also worth mentioning how you could use TLS connect string with JDBC Thin driver in case you want to establish a connection from your application. As you can imagine, you just need to slightly modify the TLS string to convert it into the JDBC connect string format. To achive that, I'm actually going to rely on a really useful command in SQLcl, SHOW CONNECTION, which shows the details of your current connection:

SQL> show connection
 ADMIN@jdbc:oracle:thin:@(description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1521)( 
 Oracle Database 19c Enterprise Edition Release - Production

Any application that uses a JDBC Thin driver to connect to ADB-S can utilize the following string that I obtained from the output above:

jdbc:oracle:thin:@(description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1521)(

Bonus content: Create a database link between two ADB-S instances

Now that we know how to enable TLS authentication and connect to our ADB-S instance without a wallet, we can move on to our bonus content: How can we create a database link between two ADB-S instances via TLS (i.e. without a wallet)? ADB-S supports TLS-based database links between ADB-S instances as of 11/07/2023 and next, we are going to see how easy it is to create a walletless database link from one ADB-S instance called adwfinance to another called sales, which has TLS enabled. 

First, we'll create a credential object in my source ADB-S instance (adwfinance) with credentials of the target ADB-S instance (sales):

        credential_name => 'SALES_DBLINK_CRED',
        username => 'ADMIN',
        password => '*************' );

PL/SQL procedure successfully completed.

Next, we'll create our database link (note that we are using port 1521 which is reserved for TLS, and directory_name is set to NULL, meaning no wallet for the target database is required):

        db_link_name => 'SALESDBLINK', 
        hostname => '', 
        port => '1521',
        service_name => 'm*******',
        credential_name => 'SALES_DBLINK_CRED',
        directory_name => NULL);

PL/SQL procedure successfully completed.

select * from dual@SALESDBLINK;



That’s as easy as it gets, isn’t it? In this post, we covered what TLS is, what benefits it brings, and how we can take advantage of it for both connectting to our ADB-S instance and creating a database link to another ADB-S instance.. If you’d like to read and learn more about the connectivity and network configuration options in ADB-S, please make sure to check our documentation.

Can Tuzla

Principal Product Manager

Can is a Principal Product Manager for Oracle Autonomous Database (ADB-S) and has been with the company since 2014. Prior to joining the ADB-S team, he worked on the Oracle Multitenant and Oracle Query Optimizer teams. Can holds a MS (Computer Science) from Case Western Reserve University and a BS (Computer Engineering) from Bilkent University.

Previous Post

Late October's newsletter for Autonomous Database

Keith Laker | 5 min read

Next Post

Announcing Select AI with Azure OpenAI Service on Oracle Autonomous Database

Mark Hornick | 6 min read
Everything you need to know about data warehousing with the world's leading cloud solution provider