Why do you need to do something that complicated? You could have
per-app/oauth-client token policies. The token policy could have a
refresh token expiration policy of never. Then everything just hooks
into existing screens and architecture.
On 11/21/2014 6:22 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de>
> To: keycloak-user(a)lists.jboss.org
> Sent: Friday, 21 November, 2014 11:29:09 AM
> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer
token and basic auth
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 11/19/2014 05:16 PM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com> To:
>>> keycloak-user(a)lists.jboss.org Sent: Wednesday, 19 November, 2014
>>> 4:01:36 PM Subject: Re: [keycloak-user] Recommendations for
>>> protecting REST service with bearer token and basic auth
>>>
>>> You guys are basically describing certificate auth.
>>
>> Yes for the one use-case I described (where the app is the user).
>> There's also the case where a user gives an application permanent
>> (offline) access to their account. In Google they have a special
>> scope you can request for this
>> (
https://developers.google.com/accounts/docs/OAuth2WebServer#offline).
>>
>>
> If there are no objections, I'll start scratching an implementation of
> this offline mode, as something on this direction will be needed for
> the project I'm helping with.
Sure, that would be great. There's a fair amount of work here though:
1. Account management needs to view clients with access and allow revoking individual
clients
2. Need some built-in special role for apps to request offline tokens
3. Need to support scope param to actually request the above role
4. Need to support client sessions that are not connected to a user session - and also
clean-up of these
5. Probably need an expiration for offline tokens, which needs to be configurable through
the admin console
>
> Ideally, the project would benefit from using service accounts instead
> of acting on behalf of an specific user, but as there will be only one
> account per user/realm, this would do for now :-)
>
> - - Juca.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJUbxP1AAoJEDnJtskdmzLM7IQH/RFJ5Cf0reec9CgMjxO1D1tt
> lgS20P6d17Ki0UocoNidp59YdP5TRKycYbCMchbfTZu4In+9gEBzsdxK+4acprPF
> sp6WCa1Comc8vFCX8Or9gxUEDRH+axWR4t/bIsBf23IvXQ1BUIVg0s21RxFoMhPP
> fGHoaAEGthez6Dhr7GSwr46FEO2xP94jHJ7nAs67DNeh0vvZmQ1iynBkF3NmfQzP
> dMCjny4i2D/UZCcSr72ud0DnoAi//vIQ86KObrqsiHV2eOhWYfHB9TozC/P1lKVM
> 5D8qByrnxtmgA/nYNuRFmKTYf2n6MZTU5AlSFJZr4svU6isl2zwkpczhwDRshjc=
> =x/UK
> -----END PGP SIGNATURE-----
>
_______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user