Hi!
I wrestle with the same question currently. A “nice to have” would be that the user can choose to restrict the API-Token.
Some of my thoughts (unfinished):
Idea:
In some sense, the OAuth 2 client-credentials Flow seems perfect. The User-App exchanges the client_credentials with short-lived access_token, uses these to access the API. Before expiry, the App can request new access_token the same way.
Service Accounts could be generated for each API-Token and they could be somehow linked to the user. Or client_credentials could be added to the User Credential Store of an existing user. Some custom Keycloak-Extension will be necessary either way.
Problem:
The Token generated for the App-Login are liked to itself as azp and not to e.g. our forum, … . This will make the normal authorization-flow unusable. Additionally the /userinfo-Endpoint seems to be nearly unpopulated for service accounts.
Solution idea:
You will have to assign the azp to the service some way -
- fetch it from a Request-Parameter during client_id validation
- store it with the token
According to Stack Overflow (and own testing with Version 15.0.2), you can assign a service-account a hardcoded protocol-mapper with azp as key and the App-ID you want to use the token with as value. I wonder however if this was intended as a feature and how future-proof this is. This will also populate the /userinfo Endpoint.
I haven’t really thought of how to link the API-Account and the normal account yet - so thats missing here.
EDIT: The Token Exchange is maybe also a way to consider - although I didn’t get it working, yet.
Anyway, API-Token seem to be a highly requested feature in IAM for which I haven’t found a satisfying solution (in combination with OIDC or SAML). (a SO-Question by me, another SO-Question, a Question in the Auth0 Community, a question here, …)
I welcome all advice! There is probably a lot of stuff I forgot to consider! (I’m pretty new to IAM)
Best regards!
Thomas (too)