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

[Stian Thorgersen]

We'll be adding service accounts in the near future, that'll provide a way for clients to obtain a token on behalf of themselves. There will be a special linked user to the client. Clients can obtain this through the client credential grant (see oauth2 for more details) and use a secret or pub/priv keypair to authenticate.

For a client to get a token on behalf of a user the user will have to either enter username/pass in a cli and you'd use resource owner credential grant (again see oauth2 for more details) or you'd use the normal redirect based flow.

For the above once we add offline tokens this will only be required as an initial setup as the "refresh token" will not expire until the user goes in and revokes access to the appliction. 

----- Original Message -----
> From: "Carsten Saathoff" <Carsten.Saathoff at kisters.de>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Juraci Paixão Kröhling" <juraci at kroehling.de>, keycloak-user at lists.jboss.org
> Sent: Wednesday, 24 June, 2015 3:43:59 AM
> Subject: Re: [keycloak-user] Refresh token - should it expire?
> 
> 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.