One option is to allow users to login through the script itself. Take a look at our customer-app-cli in the examples. It has two options one is to show the user a login that the user then opens and copy/pastes the code back to the application, the other is it opens it in a browser and can the script can then read the token directly itself. You can combine this with changing the SSO idle/max configuration for the realm to determine how often a user needs to re-authenticate. You can also combine it with offline token as well if you want the scripts to remain permanently authenticated.

Using direct access grants works as well. Rather than adding username/password to the script you should have the script request the username/password, then the script stores the token, not password. Same as above you'd configure SSO idle/max to determine how often users need to re-authenticate, or you can use offline here as well. You're right that this won't support identity brokering, that's only available for the web flow.

On 15 May 2016 at 20:59, Moshe Ben-Shoham <mosheb@perfectomobile.com> wrote:

Hi,

I’m trying to figure out the best way to secure REST APIs with KeyCloak. The REST APIs are to be invoked by unattended batch processes that are not KeyCloak clients but end-user scripts. I imagine a process in which the user generates a token using some web app and then uses this token in his scripts in order to authenticate when invoking the REST APIs.

So far I have found 2 options, but none of them seems like a very good option:

(1) Use offline tokens – according to the docs, offline token are to be used by KeyCloak clients that need to do things on behalf of the user. In my case, it is the end-user that needs the token and not a client. Should I build a dedicated client that will create the offline tokens and give them to the end-user to use? Is this a misuse for offline tokens?

(2) Use Direct Access Grants – seems like in this option, at least in its simplest form, the user needs to pass username and password to get a token. This means users need to keep their password in their scripts (or scripts configuration) and it is bad practice. In addition, what happens when KeyCloak is configured to be an Identity Broker? In this case KeyCloak does not even know how to handle the user/password.

Any help is appreciated!

The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user