<div dir="ltr">Is that not the use-case for the ‘offline tokens’ that Keycloak added support for recently?<div><br></div><div>(/me isn’t certain)</div><div><br></div><div>-Bob</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 11:44 AM, Juraci Paixão Kröhling <span dir="ltr"><<a href="mailto:juraci@kroehling.de" target="_blank">juraci@kroehling.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20.01.2016 17:12, Bill Burke wrote:<br>
> What you are describing MAKES ZERO SENSE. From your document:<br>
><br>
> "A token is created when an user reaches the path<br>
> |/secret-store/v1/tokens/create| via GET (or passing the username and<br>
> password as Basic authentication via POST) and stored into a Cassandra<br>
> data store:"<br>
><br>
> You are doing EXACTLY what the direct grant REST api does except you are<br>
> using basic auth. I still don't see the purpose of this service.<br>
<br>
</span>Those are performed in different steps. The user creates this token via<br>
an UI (or CLI, if needed), then use this key/secret as the credentials<br>
on the client.<br>
<br>
The client has no knowledge about Keycloak, OAuth, or about any meta<br>
data that was embedded into this opaque token. All it cares is that it's<br>
going to call the end service using basic auth.<br>
<br>
The secret store is *not* for every application: it's targeted to<br>
clients where OAuth handling is costly, undesirable or even impossible<br>
(like legacy applications). So, instead of entering the user's own<br>
credentials there, the key/secret are used instead.<br>
<br>
Our "metrics collector agent" is the main target for this: the knowledge<br>
about auth doesn't belong there. All it needs to know is an "user" and<br>
"password", which are the "key" and "secret" for the token. Where<br>
Keycloak is, how to create an access token from an offline token, how<br>
long to keep an access token, and so on is made at the secret store, as<br>
we need to save every processing cycle possible, to not badly influence<br>
a server that is being monitored (and possibly, already in a bad shape).<br>
<br>
Of course, if you can live with your password being stored in plaintext<br>
on the clients, you don't need the secret store. But honestly, that<br>
seems ridiculous.<br>
<div class="HOEnZb"><div class="h5"><br>
- Juca.<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>