Repository navigation
Replies: 1 comment
|
Keycloak is not a great place to model API keys directly. Offline tokens are still refresh tokens: the caller uses them to obtain access tokens, so you inherit refresh-token lifecycle, storage, revocation, rotation, and session semantics. That is usually not what people expect from an The pattern I’d use is: manage API keys in your application, store only a hash of the key, attach metadata like owner, scopes, expiry, last-used, and revoked-at, then authenticate those keys at your API boundary. Once validated, map the key to a Keycloak user/client identity for authorization decisions, or mint/exchange a short-lived internal token if your services already expect JWTs. If my answer solved your problem, please mark it as answered the question — I'm here to help, and honestly I'm also collecting Galaxy Brain badges along the way 😆 |
Uh oh!
There was an error while loading. Please reload this page.
Hello everyone,
I want to implement api key management in my app. Quite a lot of providers (openai, gitlab, and so on) allow to create a long lived key, that you can then pass to authenticate using the authorization header.
What would be the best way to implement it using keycloak?
From what I've seen, one of the primitives I can use would be the offline tokens, but since they are refresh tokens, the users would need to first create a token using the refresh flow, which gives an extra step and forces the users to handle the lifecycle of the tokens.
Of course, the first thing I want is to stay secure, so if there are good arguments in a way or another of doing things, then I can see to change the auth workflow.
This is quite close to #45275 but since it didn't get answers maybe now we have more options?
All reactions