I have an OAuth 2.0 Client ID called “secure”
Capability Config:
Client Authentication (ON)
Authorization (ON)
[v] Standard Flow [v] Direct access grants
[v] Service accounts roles
Everything works fine, i can get an token using an user called token.user with password ohyes.itworks but when i use this token to make a post to my application it authenticates using:
service-account-secure[14/Oct/2024:99:99:23 +0000] “POST /external/service/myapplication/endpoint_to_be_posted HTTP/1.1” 403 78 “-” “PostmanRuntime/7.42.0”
Instead of the user “token.user” which i used to generate the token. Anyone has a clue?
I’ve decrypted my JWT, and this is what i got:
“preferred_username”: “service-account-secure” when it should be “preferred_username”: “token.user”
Which flow did you use to create the token?
AFIK only tokens handed out through the Service Account roles
/grant_type=client_credential
flow should have a service account (but they also will always have a service account as the auth flow isn’t associated with any concrete user).
If you don’t use that flow is there a chance you accidentally add grant_type=client_credentials
when making a request to the token endpoint?
If you don’t and it still happens with e.g. the direct access grant flow (grant_type=password
) then I don’t know either.
In general it’s somewhat of a best practice to not mix service account based clients with user login based clients when it can be avoided as it can lead to quite confusing situations wrt. which scopes, roles, groups etc. apply when creating a token.
Like conceptually every client of you should have their own OIDC client in keycloak, i.e. if you have a web app that gets one client (with Standard Flow) and if you also have a background job service that gets it’s own distinct client and if you have an app it gets it’s own client (standard flow with offline_access tokens preferrably) etc. Normally following that pattern should not create a situation where you have a client which has both standard/password flow and service accounts without having at least slightly suboptimal design else where. (But then situations where slightly suboptimal design is the best thing you can do practically are quite common, too.)