<div dir="ltr">Another interesting aspect of this is that it can be useful in IoT.<div><br></div><div>In IoT the devices themselves are often pretty dumb, they have small amount of storage and don&#39;t even talk http. The hub they connect to is generally more beefy and talks both zigbee (or whatever) and http. With IoT devices it would work something like:</div><div><br></div><div>1. User registers a new IoT device through some sort of flow (click a button on the hub, through an app on the smartphone, through the web browser on the hub portal, or whatever)<br></div><div>2. The hub creates a new &quot;device&quot; account for it in Keycloak, and also gets tokens from KC (refresh or offline whatever). It stores the refresh/offline token permanently, but access token only in memory</div><div>3. The hub also creates a short token (token UUID, or key/secret pari, whatever)</div><div>4. The hub sends the small short token to the device</div><div>5. The device now only needs to store this short token and also only send this short token</div><div>6. The hub looks up the real token based on the uuid or key/secret pair, and swaps it in any outgoing request</div><div><br></div><div>Benefits here is that a small IoT device can communicate to a REST service secured with bearer tokens without having to deal with large bearer tokens, refreshing the token, etc..</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 January 2016 at 18:50, Bill Burke <span dir="ltr">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 1/20/2016 11:44 AM, Juraci Paixão Kröhling wrote:<br>
&gt; On 20.01.2016 17:12, Bill Burke wrote:<br>
&gt;&gt; What you are describing MAKES ZERO SENSE.  From your document:<br>
&gt;&gt;<br>
&gt;&gt; &quot;A token is created when an user reaches the path<br>
&gt;&gt; |/secret-store/v1/tokens/create| via GET (or passing the username and<br>
&gt;&gt; password as Basic authentication via POST) and stored into a Cassandra<br>
&gt;&gt; data store:&quot;<br>
&gt;&gt;<br>
&gt;&gt; You are doing EXACTLY what the direct grant REST api does except you are<br>
&gt;&gt; using basic auth.   I still don&#39;t see the purpose of this service.<br>
&gt; Those are performed in different steps. The user creates this token via<br>
&gt; an UI (or CLI, if needed), then use this key/secret as the credentials<br>
&gt; on the client.<br>
&gt;<br>
&gt; The client has no knowledge about Keycloak, OAuth, or about any meta<br>
&gt; data that was embedded into this opaque token. All it cares is that it&#39;s<br>
&gt; going to call the end service using basic auth.<br>
&gt;<br>
&gt; The secret store is *not* for every application: it&#39;s targeted to<br>
&gt; clients where OAuth handling is costly, undesirable or even impossible<br>
&gt; (like legacy applications). So, instead of entering the user&#39;s own<br>
&gt; credentials there, the key/secret are used instead.<br>
&gt;<br>
&gt; Our &quot;metrics collector agent&quot; is the main target for this: the knowledge<br>
&gt; about auth doesn&#39;t belong there. All it needs to know is an &quot;user&quot; and<br>
&gt; &quot;password&quot;, which are the &quot;key&quot; and &quot;secret&quot; for the token. Where<br>
&gt; Keycloak is, how to create an access token from an offline token, how<br>
&gt; long to keep an access token, and so on is made at the secret store, as<br>
&gt; we need to save every processing cycle possible, to not badly influence<br>
&gt; a server that is being monitored (and possibly, already in a bad shape).<br>
&gt;<br>
&gt; Of course, if you can live with your password being stored in plaintext<br>
&gt; on the clients, you don&#39;t need the secret store. But honestly, that<br>
&gt; seems ridiculous.<br>
</div></div>Thanks for the explanation and sorry if I sounded rude.  We have people<br>
suggesting crazy redundant shit all the time and I thought this just<br>
might have been yet another case of this.  Makes sense now.  Something<br>
interesting that we should add to Keycloak as an optional service<br>
sometime in the future.<br>
<span class="im HOEnZb"><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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>