2:03 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user