[keycloak-user] Recommendations for protecting REST service with bearer token and basic auth

[Bill Burke]

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 at kroehling.de>
>> To: keycloak-user at 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 at redhat.com> To:
>>>> keycloak-user at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com