<font size=2 face="sans-serif">Hi,</font>
<br>
<br><tt><font size=2>keycloak-user-bounces@lists.jboss.org wrote on 23/06/2015
16:50:57:<br>
<br>
> Refresh tokens should expire, but we will be adding offline tokens
<br>
> at some point which won't expire until revoked by the user or admin.<br>
</font></tt>
<br><tt><font size=2>do you have any idea how this feature will look like?
I'm asking because I will need to cover a use case in the near future,
where offline processes (e.g. periodic exports) need to access services
on behalf of a user. In other words, they need to access data with the
roles of the user who created the process initially, and as the roles are
encoded in the token they actually need to get hold of an access token
for that user. Refresh token were our first idea, but our concern was that
we needed the user to be involved in issuing the refresh token, as the
service that executes the offline processes is not the service the user
authenticates with. We use an api-gateway between the backend services
and the UI. But we don't want to expose such details about the involved
microservices to the user. And as I learned from this thread, the refresh
tokens will also expire, which is also not an option for us. Those processes
also need to run when the user is in vacation for 3 weeks.</font></tt>
<br>
<br><tt><font size=2>I have the feeling that offline tokens would be what
we actually need in our use case. But I think it would be important for
some use cases to allow for issuing of those tokens without user intervention.
I think of having an API that allows a client to request an offline token
on behalf of a user (e.g. by providing a valid access token). Obviously,
clients would need to be enabled explicitly for using such API.</font></tt>
<br>
<br><tt><font size=2>I understand that in typical OAuth flows you want
the user to be involved in such processes, but in an enterprise setting
and with a microservices architecture I would prefer to not bother the
user with having to authorize backend services that he shouldn't even know
of.</font></tt>
<br>
<br><tt><font size=2>I would really be interested in how other people solve
such scenarios (or if they do it at all) and what you think of such an
API.</font></tt>
<br>
<br><tt><font size=2>Thanks and best regards</font></tt>
<br><tt><font size=2><br>
Carsten</font></tt>
<br>
<hr>
<font size="3" face="Calibri,sans-serif">
Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany<br>Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers<br>Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff@kisters.de | WWW: http://www.kisters.de
</span>
<hr>
<font size="2" face="Calibri,sans-serif">
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. <br>This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
</font>