[keycloak-user] Recommendations for protecting REST service with bearer token and basic auth
bburke at redhat.com
Mon Nov 24 08:44:33 EST 2014
On 11/24/2014 3:44 AM, Stian Thorgersen wrote:
> There's still some unresolved issues here:
> * Never expire isn't good - it should be a longer expiration time
> * Grant page should ask the user to give the application offline access
> * User needs some way to revoke the access to the application in the future
> * Should tokens be unlinked to a user session, or should it be associated with a special user session (just setting a long expiration time for refresh tokens has no effect if user session expires)
IMO, it should be a new user session either consented to by the user or
a specific permission that the client has.
> I'm also not sure what your use-case is, is this a bash script that acts on behalf of the user? or is it a server backend script? If it's the first the flow you're suggesting works, but if it's the other it's not the correct flow.
> ----- Original Message -----
>> From: "Juraci Paixão Kröhling" <juraci at kroehling.de>
>> To: keycloak-user at lists.jboss.org
>> Sent: Friday, 21 November, 2014 6:15:24 PM
>> Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>> On 11/21/2014 05:55 PM, Bill Burke wrote:
>>> Why does a "service account" have to be anything special? Why
>>> can't it be a regular user?
>> I don't know much about the internals and the implementation of the
>> user model in KC, but from where I'm standing, it can very well be.
>> So, to recap, this is how the flow for an external client (bash
>> script) would be:
>> - - user creates an oauth client with refresh token policy set to never
>> - - bash reads the keycloak.json and refresh token from somewhere
>> - - bash uses the refresh token to obtain an access token from KC server
>> - - bash uses the access token to make the request to the backend
>> On the first run:
>> - - bash (or another CLI) builds an URL
>> - - user opens this URL, logs in and gets a code from KC server
>> - - user adds this code to the bash/CLI
>> - - bash/CLI exchanges this code for a refresh token, persisting it
>> It seems that the only change required then is to move the token
>> policy to the apps/oauth clients. If so, I'll then start scratching a
>> proposal for this change. And perhaps a shell/native (Linux) client
>> that would handle the boiler plate above.
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> -----END PGP SIGNATURE-----
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
JBoss, a division of Red Hat
More information about the keycloak-user