You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose I've got Keycloak set up as an authentication provider for many users. Now, let's say I want to have a backend service that uses the Keycloak REST API to add or remove a role on a user account based on their subscription being activated or deactivated.
I see that the REST API generally wants an access token. I assume I would create a subscription-manager account just for this backend service to make such REST calls.
But now what is going to be the backend's access token it uses to make the REST calls?
I read that I can do a /reams/(realm)/protocols/openid-connect/token POST and submit a username/password to obtain a refresh and access token. However, these tokens live only for a relatively short time, which means my backend service needs to be always obtaining a new access token, likely also requiring me to decode the JWT to see when it's going to be expired and needs a refresh. This all seems a bit unfortunately to have to do when this is a trusted backend service.. and adding no real security benefit since the backend service is in possession of the password that can always be used to create new tokens anyway.
I also understand that also the access token expiration is configurable. Though, I think that affects the all the users in the realm.
I was sort of expecting to be able to give the backend service an API token like the sort that can obtain for so many online services out there, where e.g. you manually log in, and under your account, you create an API token that lives forever.
Is there an option I haven't found yet to generate a forever-lived API token that can be used to directly authenticate with each REST API call?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Suppose I've got Keycloak set up as an authentication provider for many users. Now, let's say I want to have a backend service that uses the Keycloak REST API to add or remove a role on a user account based on their subscription being activated or deactivated.
I see that the REST API generally wants an access token. I assume I would create a subscription-manager account just for this backend service to make such REST calls.
But now what is going to be the backend's access token it uses to make the REST calls?
I read that I can do a /reams/(realm)/protocols/openid-connect/token POST and submit a username/password to obtain a refresh and access token. However, these tokens live only for a relatively short time, which means my backend service needs to be always obtaining a new access token, likely also requiring me to decode the JWT to see when it's going to be expired and needs a refresh. This all seems a bit unfortunately to have to do when this is a trusted backend service.. and adding no real security benefit since the backend service is in possession of the password that can always be used to create new tokens anyway.
I also understand that also the access token expiration is configurable. Though, I think that affects the all the users in the realm.
I was sort of expecting to be able to give the backend service an API token like the sort that can obtain for so many online services out there, where e.g. you manually log in, and under your account, you create an API token that lives forever.
Is there an option I haven't found yet to generate a forever-lived API token that can be used to directly authenticate with each REST API call?
Am I going about this wrong?
TIA
Beta Was this translation helpful? Give feedback.
All reactions