5:42 a.m.
On 3 November 2015 at 19:10, Pål Orby <orby(a)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(a)redhat.com>:
> On 03/11/15 09:32, Thomas Raehalme wrote:
>
> On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen < <sthorger(a)redhat.com>
> sthorger(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>