Redis NOAUTH Authentication Required: How to Fix It in Java

Valkey and Redis reply NOAUTH Authentication required. when the server has a password configured and the connection sending the command has not authenticated. The server is reachable and the command is valid — the connection simply has no identity attached to it yet. The error text is identical on Valkey and Redis, and everything below applies to both.

If you haven't set a password in your client, the next section fixes it in about thirty seconds. If you already set one and still see NOAUTH, skip to why it happens when you did set a password — that case has five distinct causes, and the password is rarely one of them.

The 30-Second Fix

From the command line, authenticate after connecting:

redis-cli -p 6379
127.0.0.1:6379> PING
(error) NOAUTH Authentication required.
127.0.0.1:6379> AUTH your-password
OK
127.0.0.1:6379> PING
PONG

In Java with Redisson, set the password on the server config:

Config config = new Config();
config.useSingleServer()
      .setAddress("redis://127.0.0.1:6379")
      .setPassword("your-password");

RedissonClient redisson = Redisson.create(config);

One thing to avoid: passing the password as redis-cli -a. The tool itself objects, and it is right to:

$ redis-cli -a your-password PING
Warning: Using a password with '-a' or '-u' option on the command line
interface may not be safe.
PONG

The password lands in your shell history and is visible in ps output to every user on the box. For scripts and health checks, use the REDISCLI_AUTH environment variable instead — it takes the same value and produces no warning.

What NOAUTH Actually Means

NOAUTH is one of four authentication-related replies, and telling them apart narrows the problem immediately. These are the exact strings, taken from a live server:

The distinction that matters most is NOAUTH versus WRONGPASS. WRONGPASS means your credentials reached the server and were wrong. NOAUTH means they never arrived. If you are certain the password is correct and you are getting NOAUTH rather than WRONGPASS, the problem is almost never the password itself — it is that some connection in your setup isn't sending it.

Why It Happens When You Did Set a Password

Five causes account for nearly all of these, and each one leaves the password correct while some path to the server goes unauthenticated.

1. Redis 6+ ACLs Need a Username Too

Redis 6.0 introduced ACL users. The one-argument AUTH password form still works, but as the AUTH documentation puts it, "the single argument form of the command, where only the password is specified, assumes that the implicit username is 'default'."

So if your credentials belong to a named user rather than default, a password alone authenticates as the wrong identity — or not at all. Set both:

config.useSingleServer()
      .setAddress("redis://127.0.0.1:6379")
      .setUsername("appuser")
      .setPassword("apppass");

setUsername requires Redis 6.0 or later. On older servers, leave it unset.

2. Sentinel Has Its Own Credentials

This one catches people because the password is configured and it is correct — just not for every party in the conversation. A Sentinel deployment has three separate authentication paths: your client to the data nodes, your client to Sentinel, and Sentinel to the data nodes.

On the server side, Sentinel needs credentials for the masters it monitors:

sentinel auth-user mymaster sentinel-user
sentinel auth-pass mymaster somepassword

And Sentinel itself can require a password from clients, via its own requirepass. In Redisson, that second password is a separate setting:

config.useSentinelServers()
      .setMasterName("mymaster")
      .addSentinelAddress("redis://127.0.0.1:26379")
      .setPassword("data-node-password")
      .setSentinelPassword("sentinel-password");

Redisson's documentation is precise about when you need it: sentinelPassword is "used only if Sentinel password differs from master's and slave's." If everything shares one password, setPassword alone is correct and adding setSentinelPassword changes nothing. If Sentinel has its own, the failure surfaces during topology discovery, when the client asks Sentinel for the current master address — before your application has issued a single command against the data nodes. There is a matching setSentinelUsername for ACL deployments.

3. A Replica Missing masterauth

This is the quietest failure of the five, because your application never sees the error. The replication documentation notes that if the master has a password, "it's trivial to configure the replica to use that password in all sync operations" — but nothing warns you when it hasn't been done.

A replica pointed at a password-protected master without masterauth logs this and gives up:

* Master replied to PING, replication can continue...
* (Non critical) Master does not understand REPLCONF listening-port: -NOAUTH Authentication required.
* Trying a partial resynchronization (request ...).
# Unexpected reply to PSYNC from master: -NOAUTH Authentication required.
* Retrying with SYNC...
# MASTER aborted replication with an error: NOAUTH Authentication required.
* Reconnecting to MASTER 127.0.0.1:6379 after failure

No client ever receives that error. The replica accepts connections and answers reads perfectly happily — it just serves stale or empty data, forever. The symptom your application sees is missing keys, not an authentication failure. Check for it directly:

redis-cli -p 6380 INFO replication | grep master_link_status
# master_link_status:down   <- not replicating

The fix is masterauth in the replica's config, plus masteruser if the master uses ACL users. Set it at runtime with CONFIG SET masterauth ... and the replica reconnects on its next retry; add it to the config file so it survives a restart.

4. A Cluster Node That Missed the Password

In Redis Cluster, every node authenticates independently. A client will still hit NOAUTH the moment it follows a MOVED redirect to a node whose password was never set — typically one added to the cluster later from a different config template.

The symptom is distinctive: most operations work and a specific subset fails, because only the keys hashing to that node's slots are affected. Redisson applies one credential set to every node it discovers, so the fix is on the server side — make the password uniform across the cluster.

5. Managed Redis and Expiring Tokens

On AWS ElastiCache with IAM authentication, Azure with Microsoft Entra ID, and similar managed offerings, the "password" is a short-lived token rather than a static secret. A token that authenticated at startup is not valid an hour later — the next section covers that case.

NOAUTH That Appears Hours Later

The hardest version of this problem is the one where nothing is misconfigured at startup. The application connects, runs correctly for hours or weeks, and then starts throwing NOAUTH — often intermittently, often clearing after a restart. Two mechanisms produce it.

Failover Turns a Master Into a Replica

The Sentinel documentation states plainly that "masters failed over are reconfigured as replicas when they return available." That sentence contains the trap. A node that spent its entire life as a master never needed masterauth — it was never replicating from anyone. The moment it is demoted, it does, and if that setting isn't in its config file it silently stops syncing, exactly as in cause 3.

The result is a deployment that passes every test for months and breaks the first time it fails over. Set masterauth on every node in a replicated deployment, including the ones currently acting as masters.

Credentials That Expire

The other mechanism is token rotation. An IAM or Entra ID token is valid for a bounded window — 15 minutes for ElastiCache. Configure it with a static setPassword(...) and you have captured a value that is correct exactly once. Existing connections keep working until something forces a reconnect, at which point the client re-authenticates with a token that expired long ago.

This is why the failure looks random. It isn't tied to load or to any code path — it is tied to whatever caused a new connection to open.

Redisson's answer is CredentialsResolver, which is called during connection setup rather than read once at startup, and is invoked per node address:

public class TokenCredentialsResolver implements CredentialsResolver {

    private final String username;
    private final TokenProvider tokenProvider;

    @Override
    public CompletionStage<Credentials> resolve(InetSocketAddress address) {
        String token = tokenProvider.currentToken();
        return CompletableFuture.completedFuture(new Credentials(username, token));
    }
}

config.useSingleServer()
      .setAddress("rediss://my-cache.example.com:6379")
      .setCredentialsResolver(new TokenCredentialsResolver(username, tokenProvider));

Because it runs on every connection, reconnects after a failover, a network blip or a pool refresh all pick up a current token. Cache the token inside the resolver and refresh it slightly ahead of expiry rather than minting one per connection. CredentialsResolver is available in the free edition, and Redisson ships EntraIdCredentialsResolver for Azure. For complete implementations, see the ElastiCache IAM credential provider and Microsoft Entra ID for Redis authentication on Java.

Fixing It in Java: Redisson, Jedis, Lettuce and Spring Data Redis

Every Java client supports both the password-only and username-plus-password forms. The setting names differ:

Lettuce, Spring Data Redis and redis-cli also accept credentials inside the connection URI, which is often the simplest route through a config file or environment variable:

redis://default:apppass@127.0.0.1:6379
rediss://appuser:apppass@my-cache.example.com:6379   # TLS

Redisson is the exception here, and it is a common source of this exact error. Its address setting is documented as host:port only, so credentials embedded in the address are not picked up — the connection is made and then rejected with NOAUTH. Use setUsername(...) and setPassword(...) instead.

One more URI trap that applies everywhere: the abbreviated redis://:apppass@host form, with the username left empty, is parsed inconsistently. On redis-cli 7.0 it sends an empty username and fails with WRONGPASS, while redis://default:apppass@host works. Spell out default rather than relying on the short form.

If you're moving between clients, the migration guides cover the equivalent settings in detail: Jedis to Redisson, Lettuce to Redisson, and Spring Data Redis to Redisson.

Preventing It

Watch out for health checks that pass when they shouldn't. This one is worth testing yourself, because the behaviour is counter-intuitive:

$ redis-cli -p 6379 PING
NOAUTH Authentication required.
$ echo $?
0

The command failed, printed an error, and exited zero. Any liveness or readiness probe that checks only the exit code will report a node as healthy when it is rejecting every command. Grep for PONG instead of trusting the exit status, and pass credentials to the probe via REDISCLI_AUTH. The same applies to a node still loading its dataset, which answers -LOADING. There is more on this in connecting Redisson to a Valkey or Redis cluster on Kubernetes.

Beyond that:

• Use ACL users, not a shared password. A per-service user with a scoped key pattern turns a compromised credential into a limited one, and turns NOPERM into a useful signal.
• Enable TLS. AUTH sends the password in plaintext. Use the rediss:// scheme — see connecting over TLS/SSL.
• Set masterauth everywhere, on current masters included, so a failover doesn't create cause 3.
• Keep passwords out of config files. Redisson PRO can store them AES-encrypted with an {aes} prefix and an external key file, covered in Redis password encryption on Java. That protects the secret at rest; it does not change how authentication works.

Frequently Asked Questions

How Do I Set a Password in Redis?

Add requirepass your-password to redis.conf and restart, or run CONFIG SET requirepass your-password for an immediate change that lasts until restart. On Redis 6.0 and later, prefer ACL SETUSER to create named users with scoped permissions rather than relying on a single shared password.

What Is the Default Redis Username and Password?

The default username is default, and out of the box it has no password — Redis ships with authentication disabled. Once you set requirepass, that value becomes the default user's password. This is why AUTH somepassword works without a username: it authenticates as default.

How Do I Pass a Password in a Redis Connection String?

Use redis://username:password@host:port, spelling out default as the username if you have no ACL user — the abbreviated redis://:password@host form is parsed inconsistently and fails on some clients. Use rediss:// for TLS and percent-encode special characters. Redisson is an exception: it takes credentials through setUsername and setPassword, not in the address.

What Is the Difference Between NOAUTH and WRONGPASS?

NOAUTH means no credentials were sent on that connection at all. WRONGPASS means credentials were sent and rejected — a wrong password, a username that doesn't exist, or a disabled ACL user. If you are confident the password is right and you see NOAUTH rather than WRONGPASS, look for a connection path that isn't sending it, such as Sentinel or a replica.

Why Does NOAUTH Appear Only After a Failover?

Usually because a demoted master lacks masterauth. A node that was always a master never needed it, but Sentinel reconfigures a failed-over master as a replica when it returns, and it then cannot authenticate to the new master. The other common cause is an expiring IAM or Entra ID token being reused on reconnect — solved with a CredentialsResolver rather than a static password.

How Do I Connect redis-cli With a Username and Password?

Use redis-cli --user appuser --pass apppass, or authenticate after connecting with AUTH appuser apppass. Avoid -a, which leaks the password into shell history and ps output. In scripts, set the REDISCLI_AUTH environment variable instead.

Next Steps

Most NOAUTH errors are a missing password on one connection path, not a wrong one. Work outward from the client: check that credentials are set, then that every node has the same ones, then that Sentinel and every replica have theirs.

For the full connection setup, see how to connect to Redis in Java and how to connect to a Redis cluster in Java. For how failover works and what it changes, see Redis Sentinel and master-slave replication. Every authentication setting is listed in the Redisson configuration reference.