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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-user(a)lists.jboss.org Sent: Monday, 24 November, 2014 2:44:33 PM Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth 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(a)kroehling.de&gt; >> To: keycloak-user(a)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 >> expire >> - - 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 >> afterwards >> >> 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. >> >> _______________________________________________ >> 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user