<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So far I have found 2 options, but none of them seems like a very good option:</div>
<div><br>
</div>
<div>(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?</div>
<div><br>
</div>
<div>(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. </div>
<div><br>
</div>
<div>Any help is appreciated!</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
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.
</body>
</html>