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

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Monday, 24 November, 2014 10:12:06 AM Subject: Re: [keycloak-user] Recommendations for protecting REST service with bearer token and basic auth -----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.