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

[Juraci Paixão Kröhling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/24/2014 09: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)
> 
> 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.

My concrete case is for RHQ Metrics. A system administrator would
install RHQ Metrics backend on a server and deploy a number of nodes
on a cloud or a farm. Each node would send metrics to the backend. Out
of the box, we'll provide some metrics collectors, like an Agent for
Wildfly. But the system administrator could also build shell scripts
that would gather custom information from their systems. For instance,
they might have a in-house daemon for "foo" and would parse the
foo.log for some data, sending it to the Metrics backend. Ideally,
this would be done with a simple curl call, but I'm getting hopeless
on this :)

Ideally, a token/key/secret/code that I have on the nodes wouldn't
expire. I'm fine with exchanging the code/secret with a token, but
requiring a refresh of this "stable" code from time to time could
cause some troubles. For instance, a node that hasn't received this
updated stable code would stop reporting data.

About service accounts vs. user specific offline access: for me, as a
consumer of this feature, I couldn't care less. I'd *prefer* to have
it as a service account, as I could possibly better manage it, but any
solution would be fine.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUcvZmAAoJEDnJtskdmzLM+o8H/jTAlNhnsSJTt842ThpRNcql
mTDzfGRMXMcyFJBK8kYWRFY3NY/B2n42ux8S6q/ZvxKLKye5CtbrP7rKwQuoIFZ5
BK+KQisPgYGw3CSwjB0TRW/5BawKXIoLgMRmV/fNGx8D/BeTOordyfrhBKULdKpk
+fPAsh1JdXDMV9EieQQGuX9HLhp5makG0FRVnMmw+NA967vgcPEHLBz0/NQO23I1
6HlobrH/07Z64bjcdYanxlGidJ2LIYh47lYnXHPhUSjoaK9uz5ZNZ8WQ3GW0Xg36
A/kEtexkMITmNamExnJw2E1xAMvX9lso5UjTmxH9AgMPZGFZ4Znybc7ecm+V7mE=
=6yHk
-----END PGP SIGNATURE-----