Invalid Bearer token silently falls back to anonymous access #15510

Describe the bug

When anonymous access is enabled, a request that explicitly carries an invalid Bearer token is silently treated as an anonymous request.

This makes it impossible for clients to distinguish a valid authenticated request from an invalid-token request that has fallen back to anonymous access. A user may believe the supplied token is valid while only receiving anonymously accessible resources.

Expected behavior

Authentication handling should distinguish between a missing credential and an invalid credential:

• No Authorization header: allow anonymous access when anonymous access is enabled.
• Valid Bearer token: process the request as the authenticated user.
• Invalid or expired Bearer token: return 401 Unauthorized (preferably with an appropriate WWW-Authenticate response), even when anonymous access is enabled.

An explicitly supplied invalid credential should not silently downgrade to anonymous access.

Actually behavior

Both requests below return HTTP 200 with code: 0 and the same anonymous-accessible skill list:

1. Request without an Authorization header.
2. Request with Authorization: Bearer definitely-invalid-token.

Because the response is successful and contains no authentication-state information, the caller cannot detect that the supplied token was rejected.

How to Reproduce

1. Start Nacos with anonymous access enabled so public skills can be listed without authentication.
2. Ensure at least one PUBLIC skill exists.
3. Send an anonymous request:

curl -i 'http://127.0.0.1:8848/nacos/v3/admin/ai/skills/list?pageNo=1&pageSize=1&namespaceId=public'

4. Send the same request with an invalid Bearer token:

curl -i \
  -H 'Authorization: Bearer definitely-invalid-token' \
  'http://127.0.0.1:8848/nacos/v3/admin/ai/skills/list?pageNo=1&pageSize=1&namespaceId=public'

5. Observe that both responses are HTTP 200 and return the same payload, for example:

{
  "code": 0,
  "data": {
    "pageItems": [
      {
        "name": "ppt-creator",
        "scope": "PUBLIC"
      }
    ],
    "totalCount": 1
  },
  "message": "success"
}

Desktop (please complete the following information):

• OS: macOS
• Version: Nacos 3.x local development environment
• Module: auth / AI skill
• SDK: HTTP API / nacos-cli

Additional context

This was found while adding standard Bearer-token support to nacos-cli. The CLI correctly sends Authorization: Bearer <token>, but it cannot report an invalid token because the server returns a normal anonymous success response.

The same principle should ideally apply consistently to all endpoints that support anonymous access, not only the AI skill list endpoint.