<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 November 2015 at 09:32, Thomas Raehalme <span dir="ltr"><<a href="mailto:thomas.raehalme@aitiofinland.com" target="_blank">thomas.raehalme@aitiofinland.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">* Create service account for customers - they can then use this to obtain a token (offline or standard refresh) using REST endpoints on Keycloak</div></blockquote><div><br></div></span><div>Sorry to step in, but could you please explain the use case or the reasoning for offline tokens on service accounts? If I have understood it correctly you'll still need clientId and secret to generate the access token from the offline token. Why not just use them to login whenever necessary? Thanks!<br></div></div></div></div></blockquote><div><br></div><div>I wouldn't use offline tokens myself, but if you want to provide customers with a "token" rather than a service account it should be an offline token. Problem is that it'll be rather big, not just a short "api key".</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>Best regards,<br></div><div>Thomas<br></div><div><br></div></div><br></div></div>
</blockquote></div><br></div></div>