Repository navigation
Replies: 2 comments 1 reply
|
Did you find any solution to this? I'm also looking checking this if its possible with current versions of keycloak? |
1 reply
|
Hello, @touqeershafi ! I moved forward with Option 3: Custom Keycloak SPI (Custom Grant Type) |
Maybe https://www.keycloak.org/securing-apps/jwt-authorization-grant could help you here: Your standalone API management solution creates a JWT with its own key that Keycloak trusts. And then your application sends it to Keycloak to receive an access token. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Context I am using Keycloak in my system for authentication and authorization.
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:
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.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.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.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.
All reactions