[keycloak-user] Refresh token - should it expire?

[Carsten Saathoff]

Hi,

keycloak-user-bounces at lists.jboss.org wrote on 23/06/2015 16:50:57:

> Refresh tokens should expire, but we will be adding offline tokens 
> at some point which won't expire until revoked by the user or admin.

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.

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.

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.

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.

Thanks and best regards

Carsten
--------------------------------------------------------------------------------------------------------------------------------------------
 Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany
Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers
Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de
--------------------------------------------------------------------------------------------------------------------------------------------
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. 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150624/a2cd6643/attachment-0001.html