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

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-user at 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 think you're right, but it should be possible to configure a different expiration time than for a "regular" user session. Also, should they be listed in a different section in account management, or just have a label on them?

> 
> > 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
> >> 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.
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1
> >>
> >> iQEcBAEBCgAGBQJUb3MrAAoJEDnJtskdmzLMwNoIAIHQ+NyhU+liv7D/oLIcNW4w
> >> 4mF4tFqXpmWxU989aND6XbsShmAIL67TvzNidtKEdSjUMkvYNTsgZtYEv9o5CPPt
> >> nanUmLMUEbrWJ9+Dmv4l5t83CJY4P1kSBojRzvjBeBG1FVh4sPbZfp1cXtBSccvU
> >> c0uJ/Fx7KUvvkvTUqpcy/hC72rujLor38/BVxK+MtLRPG93sFfYHN1o4FWDF+GYv
> >> t35hX6+ARANeA9c9Pqy9Rywa+y2kFRLat6rSIC5wcJO7qF9YCwUlyMiCE4seBNJC
> >> WjFmh8eVuMVryLDBZtbHpOs0N9XmM7QvI4ydM7EmWQQ9TWbs/I1TmPqPEjacGGs=
> >> =n6oJ
> >> -----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
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user