Need a solution for the Automatic Rotation of Public key in the KEYCLOAK for APISIX jwt-auth plgin.

[chandreshreddyg17]

I have deployed APISIX in decoupled mode . I am using jwt-auth plug in to validate the token locally and Identify the consumer ,apply the plugins which are in consumer.
I gave KEYCLOAK Realm public key in the Consumer of APISIX.

My issue is that The KEYCLOAK public key automatically rotates for every 10 years. At that time the jwt tokens will not be validated.

Is there any approach or solution for this.

-Chandresh Reddy
Thanks in advance

[dosubot[bot]]

Hi @chandreshreddyg17! I'm Dosu and I'm helping the APISIX team.

The jwt-auth plugin does not support automatic JWKS key rotation — it requires the public key to be statically configured in each consumer credential [1]. There's a feature request for JWKS endpoint support in jwt-auth, but it hasn't been implemented yet.

The recommended solution is to switch to the openid-connect plugin, which has native support for automatic key fetching from Keycloak's JWKS endpoint. Here's what you'd configure:

• use_jwks = true — the plugin will automatically fetch and rotate keys from your Keycloak realm's JWKS endpoint [2]
• bearer_only = true — for API gateway scenarios where you only need local token validation (no browser redirect flows)
• client_secret is optional when using bearer_only + use_jwks [3]

An added benefit: the openid-connect plugin can validate tokens directly against Keycloak's discovery endpoint without requiring pre-registered Consumers in APISIX [4]. However, if you need consumer-level plugin configuration, you can still map claims to consumers.

If you must stay on jwt-auth, the only option today is to manually update the consumer's public_key via the Admin API whenever Keycloak rotates its key (or automate that externally with a script that fetches from Keycloak's JWKS endpoint and PUTs to APISIX's Admin API).

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dosubot[bot]]

@chandreshreddyg17 The openid-connect plugin can be configured at the route level or service level — not at the consumer level [1].

This makes sense architecturally because:

• Route/Service level — defines how to validate tokens (which Keycloak realm, client_id, discovery URL, etc.). All requests hitting that route go through the same OIDC validation.
• Consumer level — is where you define what policies to apply per-user (rate limits, request transforms, etc.). Consumers are identified by auth plugins, not the other way around.

For your setup, the flow would be:

Level	What to configure
Route	openid-connect (token validation + JWKS) and oidc-consumer-mapper (your custom plugin)
Consumer	Per-user plugins like limit-count, proxy-rewrite, etc.

If you have multiple routes that all use the same Keycloak realm, you can attach openid-connect at the service level and associate that service with all your routes — avoids repeating the config on every route.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chandreshreddyg17]

@dosu
got it, can you give me order or levels of execution of plugins

[dosubot[bot]]

@chandreshreddyg17 APISIX executes plugins in descending priority order — higher number runs first [1].

Here's the execution order for the plugins relevant to your setup:

Priority	Plugin	Role
2599	openid-connect	Validates JWT against Keycloak JWKS [2]
2550	oidc-consumer-mapper (your custom plugin)	Extracts claim → attaches consumer
2510	jwt-auth	JWT authentication [3]
2500	key-auth	API key authentication [4]
2400	consumer-restriction	Restricts access by consumer/group [5]
1008	proxy-rewrite	Rewrites upstream URI/headers [6]
1002	limit-count	Rate limiting by count [7]
1001	limit-req	Rate limiting by request rate [8]

So for your flow:

1. openid-connect (2599) → validates the token, sets X-ID-Token header
2. oidc-consumer-mapper (2550) → reads the claim, attaches consumer
3. Consumer-level plugins apply → rate limits, restrictions, etc.

You can also override any plugin's priority per-route using _meta.priority in the plugin config if needed.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chandreshreddyg17]

@dosu
Thank you , I got clear now

[dosubot[bot]]

Glad it's clear now, @chandreshreddyg17! Good luck with your Keycloak + openid-connect setup. Feel free to come back if you run into any issues during implementation. 👍

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chandreshreddyg17]

@dosu
I have a another doubt, how can we achieve the tenant level plugins here,ws02 has tenant concept , how can we achieve the topic here

[dosubot[bot]]

@chandreshreddyg17 APISIX doesn't have a built-in "tenant" primitive like WSO2, but you can achieve tenant-level plugin isolation using Consumer Groups — this is the closest equivalent [1].

How Consumer Groups Work as Tenants

1. Create a consumer group per tenant with shared plugins (rate limits, transformations, etc.):

curl http://127.0.0.1:9180/apisix/admin/consumer_groups/tenant-acme -X PUT \
  -H "X-API-KEY: ${admin_key}" \
  -d '{
    "plugins": {
      "limit-count": {
        "count": 10000,
        "time_window": 3600
      }
    }
  }'

2. Assign consumers to a tenant group via group_id:

curl http://127.0.0.1:9180/apisix/admin/consumers -X PUT \
  -H "X-API-KEY: ${admin_key}" \
  -d '{
    "username": "user-alice",
    "group_id": "tenant-acme",
    "plugins": {
      "limit-count": {
        "count": 500,
        "time_window": 3600
      }
    }
  }'

3. Plugin merge behavior [2]:
   • Consumer group plugins apply to all consumers in that group
   • Individual consumer plugins override group-level plugins of the same type
   • So you get tenant-wide defaults with per-user overrides

Tying It to Your openid-connect Setup

In your custom oidc-consumer-mapper plugin, you could extend the logic to also set the group_id based on a Keycloak claim (e.g., organization or a custom tenant_id claim):

-- In your custom plugin, after extracting claims:
local tenant_id = claims.organization or claims.tenant_id

local apisix_consumer = {
    consumer_name = consumer_name,
    username = consumer_name,
    credential_id = claim_value,
    group_id = "tenant-" .. tenant_id,  -- maps to consumer group
    ...
}

Plugin Hierarchy (top to bottom)

Level	Scope	Example
Global	All requests	Logging, metrics
Service	All routes using that service	Shared auth config
Route	Single route	openid-connect, your custom plugin
Consumer Group	All consumers in the group	Tenant-level rate limits, transforms
Consumer	Single consumer	Per-user overrides

Consumer plugins always win over consumer group plugins for the same plugin type [3].

Additional Tenant Isolation Features

Some plugins have built-in tenant isolation:

• proxy-cache has a consumer_isolation option that namespaces cache per consumer/group [4]
• limit-count / ai-rate-limiting can key counters by $consumer_group_id for shared tenant quotas [5]

So the pattern is: Consumer Group = Tenant, with tenant-level plugins defined on the group and per-user overrides on individual consumers.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chandreshreddyg17]

@dosu
can we use one opendid-connect for the both password grant (client 1 in keycloak of ) and client credentials (client 2 in keycloak) in the same realm .

[dosubot[bot]]

You've reached the anonymous usage limit of 10 interactions per month. Your usage will reset on 2026-07-01. If you'd like to use Dosu before then, please register to increase your limit to 100 interactions per month for free.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.