Create API Token that are "impersonating" a user

Getting advice
1

Hi,
I’ve been investigating how to create some kind of “API Token” that can be used to authenticate a user without the need of its password. The general use case is as follows:

  1. User: The user logs in with his account (username:password)
  2. User: The user create an API Token on our dashboard
  3. System: Generate said Token
  4. User: Configure the token inside a separate application (but no password)

Worth noting that step 3 and 4 could potentially be done several times, and is fully in control of the user.

So far I’ve been thinking about doing this with a long-lived token generated into a separate client (due to the need of long-lived session configuration) so that the session stays open and can be cleared out when needed.

I read that we can create a client for this, but then I’m not sure how this should be configured to make sure the client has the exact same group/role/permission than the user.

Does this sound like a good idea or am I over-complicating it?
Is there any other way that should be the “normal way”?

Thanks in advance for the insights!

Best,
Thomas

1 Like
2

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)