Using Keycloak Realm's Public Key in Jwt-Auth Plugin for Authentication.

[chandreshreddyg17]

I have deployed APISIX in a decoupled mode. I need to do the authentication for the consumer (applications), I am representing Keycloak clients as a Applications. I want to use the jwt-auth using the Public Key of the Realm of Keycloak to Authenticate the Consumers locally ,instead of asking the Keycloak again and again for every request using OpenId-Connect.
Is this a better approach ? do we have any approach better than this??
@dosu

[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 20 interactions per month for free.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[dosubot[bot]]

Yes, using Keycloak's realm public key with the jwt-auth plugin for local verification is a valid approach — and it works well for stateless, low-latency API-to-API authentication where you already have pre-issued tokens.

Here's how to set it up:

1. Create a Consumer with Keycloak's public key:

{
  "username": "my-app",
  "plugins": {
    "jwt-auth": {
      "key": "my-app-key",
      "algorithm": "RS256",
      "public_key": "-----BEGIN PUBLIC KEY-----\n<Keycloak realm RSA public key>\n-----END PUBLIC KEY-----"
    }
  }
}

2. Enable jwt-auth on your route and set key_claim_name to a JWT claim that identifies the consumer (e.g., "azp", "sub", or a custom claim matching the key above) [1].

Important caveat: The plugin requires a claim in the Keycloak-issued JWT to match an APISIX Consumer's key. This creates a management coupling — every Keycloak client needs a corresponding APISIX Consumer registered with the matching key [2].

---

Is there a better approach?

For most Keycloak integrations, the openid-connect plugin is the recommended choice [3] [4]. It can also validate JWTs locally using Keycloak's JWKS endpoint (no per-request call to Keycloak for token introspection), plus it gives you:

• Automatic JWKS key rotation handling (no manual public key updates)
• Token refresh support
• Multiple auth flows (client credentials, authorization code, etc.)
• Session management

Use jwt-auth if you specifically need the simplest possible stateless verification with minimal configuration and don't need any of the above features.

Use openid-connect if you want a production-grade Keycloak integration that handles key rotation, supports multiple flows, and doesn't require manually syncing Consumers with Keycloak clients.

Would you like a concrete configuration example for either approach?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chandreshreddyg17]

Got it @dosu ,
I am currently working with APISIX deployed in decoupled mode, and I am using Keycloak as the Identity and Access Management (IAM) solution.
My design approach is as follows:
Each Keycloak client (application) is treated as a Consumer in APISIX.
Token validation is performed using the jwt-auth plugin at the Consumer level.
I need to enforce request limits and platfrom at three different levels: Consumer, Route, and Tenant.

So the keycloak's clinet/application is consumer.
keycloak's tenant is consumer group (means the all the consumer shares the same puligns)

For this , what i have done is that , I wrote a serverless pre function to extract the name of the tenant and applied the tenant level rate limiting (limit-count),
At the consumer group ,I wrote a rate limiting (limit-count) and called this id so all the consumers have that rate limiting .
At the route level , I implemented a rate limiting (limit-req) .

All the levels (Route, Consumer and Tenant ) Level Plugins are working good,

I will change the keycloak's realm public key for every 6 months and keyclok's client secret for 6 months.

I am following this approach is because I have a api's which needs to be consumed by only some applications(clients) . And Isolation of tenants and applications for api usage and token .

This is my approach, so tell me , is this good or not , Any recommendations, any risks.
tell me overall about this

[dosubot[bot]]

Your overall architecture is solid — mapping Keycloak clients to APISIX Consumers and Keycloak tenants to Consumer Groups is a clean design. Here's my assessment:

What's working well:

• Consumer ↔ Keycloak client mapping — makes sense for per-application authentication and rate limiting.
• Consumer Groups for tenants — this is exactly what Consumer Groups are designed for: sharing plugin configs (like limit-count) across all consumers in a tenant [1].
• Multi-level rate limiting — using limit-count at consumer/tenant level and limit-req at route level works because they are different plugins and execute independently. The plugin precedence order is: Consumer > Consumer Group > Route > Service [2].

One important caveat on plugin merging: if you configure limit-count at both the Consumer and Consumer Group levels, the Consumer-level config overrides (not stacks with) the Consumer Group config, because consumer plugins have higher precedence [3]. So make sure your tenant-level limit-count and consumer-level limit-count aren't competing — you may want to keep limit-count only at the Consumer Group level for tenant limits and use a different mechanism at the consumer level.

Two recommendations:

1. Key rotation is the biggest risk. The jwt-auth plugin does not support JWKS or automatic key rotation [4]. When you rotate Keycloak's realm public key every 6 months, you'll need to manually update the public_key on every Consumer in APISIX. If there's any delay, tokens signed with the new key will be rejected, causing downtime. Consider using the openid-connect plugin with use_jwks: true instead — it auto-discovers Keycloak's JWKS endpoint and handles key rotation transparently with a configurable cache TTL (jwk_expires_in, default 86400s) [5].

2. Replace serverless-pre-function for tenant extraction. Instead of a custom Lua function to parse the JWT for tenant info, the jwt-auth plugin has a store_in_ctx: true option that exposes the full JWT payload to downstream plugins via ctx.jwt_auth_payload [4]. This is more maintainable than custom code. If you switch to openid-connect, it natively injects X-Userinfo headers containing tenant claims [5].

Summary: The design pattern is sound. The main risk is operational — manual key rotation across many Consumers is error-prone. If you can switch to openid-connect with bearer_only: true and use_jwks: true, you get the same stateless local JWT verification but with automatic key rotation. If you must stay with jwt-auth, consider storing the public key via an environment variable reference ($env://KEYCLOAK_PUBLIC_KEY) so you can rotate it in one place rather than per-Consumer.

Would you like a concrete openid-connect configuration example for your Keycloak setup, or help with the store_in_ctx approach for tenant extraction?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[chandreshreddyg17]

@dosu ,
The reason that I am using the jwt-auth is to validate the tokens locally instead of hitting the keycloak everytime and also the jwt-auth automatically identifies the consumer name, which i want to use to check the api consumption, so I want to go with the jwt-auth , For every 6 months i will update the keycloak realm public key, which is not a big deal ,

so based on this , give me the review for my approach .

[dosubot[bot]]

Fair enough — jwt-auth with local validation and automatic consumer identification is a valid choice for your use case. Here's my review of your approach, given your constraints:

✅ What's good:

• Keycloak client → APISIX Consumer mapping with jwt-auth (RS256) gives you stateless local validation and automatic consumer identification via X-Consumer-Username [1]. This is clean for tracking API consumption per application.
• Consumer Groups for tenants — correct use of the feature. Shared limit-count applies to all consumers in the group without duplicating config.
• Using different rate-limiting plugins at different levels (limit-count for tenant/consumer, limit-req for route) — since these are different plugins, they execute independently and don't conflict.

⚠️ Things to watch out for:

1. limit-count at both consumer and consumer-group levels will NOT stack — the consumer-level config overrides the consumer-group one entirely, because the same plugin only runs once per request using the highest-precedence config (Consumer > Consumer Group > Route) [2]. If you need both a per-consumer limit and a per-tenant limit using limit-count, you'll need to use the _meta.priority field to run two instances, or use limit-count at one level and a different plugin (like limit-req) at the other.

2. Serverless pre-function for tenant extraction — consider replacing this with store_in_ctx: true on the jwt-auth route config. This exposes the full JWT payload via ctx.jwt_auth_payload, so downstream plugins or serverless functions can read tenant claims directly without re-parsing the token [1]. Less custom code, fewer things to break.

3. Key rotation tip — instead of updating every Consumer's public_key individually, store the key via an environment variable reference ($env://KEYCLOAK_PUBLIC_KEY) or HashiCorp Vault ($secret://vault/...). That way, rotation is a single env var or Vault update + APISIX reload rather than N Consumer API calls [1].

4. No token revocation — jwt-auth is purely stateless, so there's no way to revoke a token before expiry. Keep your token exp reasonably short (e.g., 5–15 minutes) and rely on Keycloak's refresh token flow on the client side. This minimizes the window if a token is compromised.

Overall: The approach is sound for your requirements. The main things to tighten up are the limit-count override behavior (make sure you're not accidentally losing the tenant-level limit), using store_in_ctx instead of custom serverless parsing, and centralizing the public key via env var/Vault for easier rotation.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.