[keycloak-user] Generate offline token
Pål Orby
orby at sendregning.no
Thu Nov 5 07:19:49 EST 2015
I'm currently implementing the proxy solution.
Thanks for you help :-)
*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-05 12:42 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>
> On 3 November 2015 at 19:10, Pål Orby <orby at sendregning.no> wrote:
>
>> 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?
>>
>
> No, we don't have any plans for that. However as I suggested you can
> relatively easily provide that yourself by creating a client with service
> account for a customer then create an offline token to send to them. Main
> issue still stands though is that an offline token is not just a short "API
> Key" it's a relatively big base64 string.
>
> If you want a short "API Key" you'd need a proxy in front of your services
> that can swap the key for the actual token.
>
>
>>
>> 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 at redhat.com>:
>>
>>> On 03/11/15 09:32, Thomas Raehalme wrote:
>>>
>>> On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen <
>>> <sthorger at redhat.com>sthorger at 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 listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20151105/3943e3d4/attachment.html
More information about the keycloak-user
mailing list