alibaba/nacos · error · AccessException

403

403

Error message

Code: %d, Message: %s.

What it means

Thrown by RemoteRequestAuthFilter (gRPC/internal-request auth filter) at the identity-validation stage (line 116). After parsing the identity from the request, protocolAuthService.validateIdentity(...) is called; if the identity cannot be authenticated (bad/missing/expired token, no credentials), AuthResult.isSuccess() is false and an AccessException with result.format() is thrown. This is an authentication denial on a remote (gRPC) request. The filter catches AccessException and returns a 403 (NO_RIGHT) response.

Source

Thrown at core/src/main/java/com/alibaba/nacos/core/auth/RemoteRequestAuthFilter.java:116

                        return defaultResponseInstance;
                    case MATCHED:
                        return null;
                    default:
                        break;
                }
                if (!protocolAuthService.enableAuth(secured)) {
                    return null;
                }
                String clientIp = meta.getClientIp();
                request.putHeader(Constants.Identity.X_REAL_IP, clientIp);
                Resource resource = protocolAuthService.parseResource(request, secured);
                IdentityContext identityContext = protocolAuthService.parseIdentity(request);
                AuthResult result = protocolAuthService.validateIdentity(identityContext, resource);
                requestContext.getAuthContext().setIdentityContext(identityContext);
                requestContext.getAuthContext().setResource(resource);
                requestContext.getAuthContext().setAuthResult(result);
                if (!result.isSuccess()) {
                    throw new AccessException(result.format());
                }
                String action = secured.action().toString();
                result = protocolAuthService.validateAuthority(identityContext,
                    new Permission(resource, action));
                if (!result.isSuccess()) {
                    throw new AccessException(result.format());
                }
            }
        } catch (AccessException e) {
            if (Loggers.AUTH.isDebugEnabled()) {
                Loggers.AUTH.debug("access denied, request: {}, reason: {}",
                    request.getClass().getSimpleName(),
                    e.getErrMsg());
            }
            Response defaultResponseInstance = getDefaultResponseInstance(handlerClazz);
            defaultResponseInstance.setErrorInfo(NacosException.NO_RIGHT, e.getErrMsg());
            return defaultResponseInstance;
        } catch (Exception e) {

View on GitHub (pinned to 9b989acdf1)

Solutions

  1. Provide valid credentials: set username/password or AccessToken in the client SDK config.
  2. If using server-identity auth, ensure the identity key/value headers match the server config.
  3. Refresh expired tokens.
  4. Verify the auth plugin type matches between client and server.

Example fix

// before (Java client, no auth)
NamingService naming = NamingFactory.createNamingService("127.0.0.1:8848");

// after (with credentials)
Properties props = new Properties();
props.setProperty(PropertyKeyConst.SERVER_ADDR, "127.0.0.1:8848");
props.setProperty(PropertyKeyConst.USERNAME, "nacos");
props.setProperty(PropertyKeyConst.PASSWORD, "nacos");
NamingService naming = NamingFactory.createNamingService(props);
Defensive patterns

Strategy: try-catch

Validate before calling

// Java SDK: ensure credentials are configured before creating the service
Properties props = new Properties();
props.setProperty(PropertyKeyConst.SERVER_ADDR, serverAddr);
if (authEnabled) {
  props.setProperty(PropertyKeyConst.USERNAME, username);
  props.setProperty(PropertyKeyConst.PASSWORD, password);
  // or: props.setProperty(PropertyKeyConst.ACCESS_TOKEN, token);
}

Try / catch

try {
  namingService.registerInstance(serviceName, ip, port);
} catch (NacosException e) {
  if (e.getErrCode() == NacosException.NO_RIGHT) {
    // identity validation failed — refresh token / check credentials
    refreshCredentials();
  }
}

Prevention

When it happens

Trigger: A gRPC/remote request to a @Secured handler with no AccessToken header, an expired token, an invalid token signature, or credentials that fail identity validation. Distinct from 1039 (authority): this is 'who are you?' failing, not 'are you allowed?'. E.g. a client SDK with no auth config connecting to an auth-enabled server.

Common situations: Client SDK not configured with username/password or access token. Token expired. Server identity header mismatch when using server-identity auth. Username/password changed server-side but client caches old creds. gRPC client connecting without the auth interceptor.

Related errors


AI-assisted analysis of alibaba/nacos@9b989acdf1 (2026-08-14). Data as JSON: /api/errors/40556d897df35cce. Report an issue: GitHub.