Advanced connection information

Connection URI

The driver supports connection to URIs of the form

<SCHEME>://<HOST>[:<PORT>[?policy=<POLICY-NAME>]]

<SCHEME> is one among neo4j, neo4j+s, neo4j+ssc, bolt, bolt+s, bolt+ssc.
<HOST> is the host name where the Neo4j server is located.
<PORT> is optional, and denotes the port the Bolt protocol is available at.
<POLICY-NAME> is an optional server policy name. Server policies need to be set up prior to usage.

The driver does not support connection to a nested path, such as example.com/neo4j/. The server must be reachable from the domain root.

Connection protocols and security

Communication between the driver and the server is mediated by Bolt. The scheme of the server URI determines whether the connection is encrypted and, if so, what type of certificates are accepted.

URL scheme	Encryption	Comment
neo4j		Default for local setups
neo4j+s	(only CA-signed certificates)	Default for Aura
neo4j+ssc	(CA- and self-signed certificates)

URL scheme

Encryption

Comment

neo4j

Default for local setups

neo4j+s

(only CA-signed certificates)

Default for Aura

neo4j+ssc

(CA- and self-signed certificates)

The driver receives a routing table from the server upon successful connection, regardless of whether the instance is a proper cluster environment or a single-machine environment. The driver’s routing behavior works in tandem with Neo4j’s clustering by directing read/write transactions to appropriate cluster members. If you want to target a specific machine, use the bolt, bolt+s, or bolt+ssc URI schemes instead.

The connection scheme to use is not your choice, but is rather determined by the server requirements. You must know the right server scheme upfront, as no metadata is exposed prior to connection. If you are unsure, ask the database administrator.

Authentication methods

Basic authentication

The basic authentication scheme relies on traditional username and password. These can either be the credentials for your local installation, or the ones provided with an Aura instance.

const driver = neo4j.driver(URI, neo4j.auth.basic(USER, PASSWORD))

The basic authentication scheme can also be used to authenticate against an LDAP server (Enterprise Edition only).

Kerberos authentication

The Kerberos authentication scheme requires a base64-encoded ticket. It can only be used if the server has the Kerberos Add-on installed.

const driver = neo4j.driver(URI, neo4j.auth.kerberos(ticket))

Bearer authentication

The bearer authentication scheme requires a base64-encoded token provided by an Identity Provider through Neo4j’s Single Sign-On feature.

const driver = neo4j.driver(URI, neo4j.auth.bearer(token))

The bearer authentication scheme requires configuring Single Sign-On on the server. Once configured, clients can discover Neo4j’s configuration through the Discovery API.

Custom authentication

If the server is equipped with a custom authentication scheme, use neo4j.auth.custom.

const driver = neo4j.driver(
  URI,
  neo4j.auth.custom(principal, credentials, realm, scheme, parameters)
)

No authentication

If authentication is disabled on the server, the authentication parameter can be omitted entirely.

Rotating authentication tokens

It is possible to rotate authentication tokens that are expected to expire (e.g. SSO). You need to provide a AuthTokenManager instance when instantiating the Driver, rather than a static authentication token.

The easiest way to get started is to use one of built-in AuthTokenManager implementations.

Rotating a bearer token expiring every 60 seconds

import neo4j, { AuthToken } from 'neo4j-driver'

/**
 * Method called whenever the driver needs to refresh the token.
 *
 * The refresh will happen if the driver is notified by the server
 * of token expiration, or if `Date.now() > tokenData.expiry`.
 *
 * The driver will block creation of all connections until
 * this function resolves the new auth token.
 */
async function generateAuthToken () {
   const bearer = await getSSOToken()  // some way to get a token
   const token = neo4j.auth.bearer(bearer)

   // assume we know tokens expire every 60 seconds
   const expiresIn = 60
   // Include a little buffer so that new token is fetched before the old one expires
   const expiration = expiresIn - 10

   return {
      token,
      // if expiration is not provided,
      // the driver will only fetch a new token when an auth failure happens
      expiration
   }
}

const driver = neo4j.driver(
    URI,
    neo4j.authTokenManagers.bearer({
        tokenProvider: generateAuthToken
    })
)

This API must not be used for switching users. Auth managers must always return tokens for the same identity. You can switch users at both query level and session level.

AuthManagers (including provider functions passed to expirationBasedAuthTokenManager()) must not interact with the driver in any way, as this can cause deadlocks and undefined behavior.

Mutual TLS (client-side certificates as 2FA)

Mutual TLS (mTLS) allows you to use a client certificate as second factor for authenticating with the server. The certificate can only be used together with an authentication token and is not a replacement of regular authentication, unless authentication is disabled on the server.

The client’s certificate and public key must be placed in the server’s <NEO4J_HOME>/certificates/bolt/trusted directory. For more information on server setup, see Configure SSL over Bolt.

For mTLS to work, the driver’s connection with the server must be encrypted, i.e. the connection URI scheme must be either +s or +ssc (ex. neo4j+s://example.com:7687).

Use the driver configuration option clientCertificate to provide the certificate information as an object.

const driver = neo4j.driver(URI, neo4j.auth.basic(USER, PASSWORD), {
   clientCertificate: {
      certfile: '/path/to/cert.cert',
      keyfile: '/path/to/cert.pem',
      password: 'the_key_password' // optional
   }
})

Instantiate the certificate object via clientCertificateProviders.rotating and provide it when instantiating the driver via the configuration option clientCertificate.

const initialClientCertificate: {
  certfile: '/path/to/cert.cert',
  keyfile: '/path/to/cert.pem',
  password: 'the_key_password' // optional
}
const clientCertificateProvider = neo4j.clientCertificateProviders.rotating({
    initialCertificate: initialClientCertificate
})
const driver = neo4j.driver(URI, MY_CREDENTIALS, {
   clientCertificate: clientCertificateProvider
})
// use the driver...
// ... until it's time to update the certificate
clientCertificateProvider.updateCertificate({
  certfile: '/path/to/new_cert.cert',
  keyfile: '/path/to/new_cert.pem',
  password: 'the_new_key_password' // optional
})
// use the driver some more

Custom address resolver

When creating a Driver object, you can specify a resolver function to resolve the connection address the driver is initialized with. Note that addresses that the driver receives in routing tables are not resolved with the custom resolver.

Connection to example.com on port 9999 is resolved to localhost on port 7687

let URI = 'neo4j://example.com:9999'
let addresses = [
  'localhost:7687'
]
let driver = neo4j.driver(URI, neo4j.auth.basic(USER, PASSWORD), {
  resolver: address => addresses
})

Further connection parameters

You can find all Driver configuration parameters in the API documentation.

Glossary

LTS: A Long Term Support release is one guaranteed to be supported for a number of years. Neo4j 4.4 is LTS, and Neo4j 5 will also have an LTS version.
Aura: Aura is Neo4j’s fully managed cloud service. It comes with both free and paid plans.
Cypher: Cypher is Neo4j’s graph query language that lets you retrieve data from the database. It is like SQL, but for graphs.
APOC: Awesome Procedures On Cypher (APOC) is a library of (many) functions that can not be easily expressed in Cypher itself.
Bolt: Bolt is the protocol used for interaction between Neo4j instances and drivers. It listens on port 7687 by default.
ACID: Atomicity, Consistency, Isolation, Durability (ACID) are properties guaranteeing that database transactions are processed reliably. An ACID-compliant DBMS ensures that the data in the database remains accurate and consistent despite failures.
eventual consistency: A database is eventually consistent if it provides the guarantee that all cluster members will, at some point in time, store the latest version of the data.
causal consistency: A database is causally consistent if read and write queries are seen by every member of the cluster in the same order. This is stronger than eventual consistency.
NULL: The null marker is not a type but a placeholder for absence of value. For more information, see Cypher → Working with null.
transaction: A transaction is a unit of work that is either committed in its entirety or rolled back on failure. An example is a bank transfer: it involves multiple steps, but they must all succeed or be reverted, to avoid money being subtracted from one account but not added to the other.
backpressure: Backpressure is a force opposing the flow of data. It ensures that the client is not being overwhelmed by data faster than it can handle.
transaction function: A transaction function is a callback executed by an executeRead or executeWrite call. The driver automatically re-executes the callback in case of server failure.
Driver: A Driver object holds the details required to establish connections with a Neo4j database.