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)
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>
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.
-----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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user