Ok, so after reading the replies here I understand that it isn't offline tokens I'm looking for.

The token I'm looking for is what I would call an "application token". Any plans implementing that?

Example:
If you enable two factor authentication on Github, you can't connect with username/password anymore in terminal or other 3. party applications integrated with GitHub without using an "application token" that you create on your GitHub account page.

/Pål

Pål Orby
UNIT4 Agresso AS
Programvareingeniør
Tlf: 22 58 85 00
Mobil: 900 91 705

SendRegning - Gjør det enkelt!
http://www.sendregning.no
http://facebook.com/sendregning
http://twitter.com/sendregning
http://faktura.no

2015-11-03 13:49 GMT+01:00 Marek Posolda <mposolda@redhat.com>:
On 03/11/15 09:32, Thomas Raehalme wrote:
On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen <sthorger@redhat.com> wrote:
* Create service account for customers - they can then use this to obtain a token (offline or standard refresh) using REST endpoints on Keycloak

Sorry to step in, but could you please explain the use case or the reasoning for offline tokens on service accounts? If I have understood it correctly you'll still need clientId and secret to generate the access token from the offline token. Why not just use them to login whenever necessary? Thanks!
We support offline tokens for service accounts because there is no reason (bad side effect) of not supporting it. Or at least I am not aware of any. Are you? Adding this support came "for free".

One usecase when it can be useful is, for example if you have offline token and you don't know how was this offline token authenticated (if it was direct grant, service account or browser). You can send the refresh token request with this token regardless of the offline token type as the refreshToken endpoint is same for all cases.

Marek

Best regards,
Thomas




_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user