Context I am using Keycloak in my system for authentication and authorization.

• I have a "public" client used by users to login from the UI (requesting access and refresh tokens).
• I have an "authorization" client where authorization rules are configured for users.

On access token generation, all permissions are added to the JWT token. Later, I use these permissions to locally authorize the user.

The Goal: I am working on an is implementation of static API keys. These are not Keycloak access/refresh tokens, but static strings that users can add to a request without needing to handle refreshes.

As Keycloak doesn't provide this feature out of the box, I am going to implement it on my own. In short:

1. Allow the user to create API keys for themselves with some TTL.
2. In the API Gateway, on a request with a static API key:
   2.1. Verify that the token is valid/not revoked (DB/cache lookup).
   2.2. Exchange it for an access_token and pass it to downstream services (propagating user and authz info).

The Problem: The main problem here is point 2.2. I am not sure how to exchange a static API token for a Keycloak access_token.

Here are the options I considered:

1. Direct Naked Impersonation
   1.1. To make this work, I need to enable one preview feature ("token-exchange") and one deprecated feature ("admin-fine-grained-authz:v1"). (documentation: If you still need legacy token exchange feature, you also need Fine-grained admin permissions version 1 (FGAP:v1) enabled)
   1.2. A solution built on a deprecated feature doesn't sound good enough.
2. Offline Access Token
   2.1. During API key creation, exchange the user's access_token for an offline_access refresh token. Store the refresh token next to the API key in the DB.
   2.2. On request, request an access_token using the stored offline_access refresh token.
   2.3. This approach won't work, as Keycloak doesn't support token exchange for a refresh token for a session other than the current one (documentation: Similarly it will not be allowed to request an offline token, similar discussion).
3. Custom Keycloak SPI (Custom Grant Type)
   3.1. Create a custom Java extension for Keycloak that implements a new grant_type (e.g., grant_type=api_key).
   3.2. Pass the static API key from the Gateway to Keycloak.
   3.3. The extension logic will verify the key against the DB, lookup the user, and mint a standard access token internally.
   3.4. Alternatively, verify the token in the app and implement a custom "impersonation endpoint" that returns an access_token for the requested user ID. This is effectively a reimplementation of "Direct Naked Impersonation," but it avoids using deprecated features.

I believe Option 3 is the only working solution, but it forces me to maintain a lot of custom code.
However, this use case seems quite standard. Am I missing something?

I would be very grateful if someone could advise on a better solution here.