[keycloak-dev] Persistent token

Stian Thorgersen stian at redhat.com
Wed May 27 05:50:27 EDT 2015


Just discussed this idea with Juraci on IRC:

1. Hawkular console provides a mechanism to link an agent
   - Hawkular creates a client on behalf of the agent
   - Hawkular creates a refresh token using the direct grant api and stores this in a db
   - Hawkular console displays a reference to the token to the admin
   - Admin copy/paste the reference into the agent

2. When agent invokes Hawkular it includes the token reference in the Authorization header

3. A proxy/filter in front of Hawkular services swaps the token reference with an access token
   - It should keep access tokens in memory, if one exists for the ref, it should check expiration. If still valid just swap reference in header with access token
   - If access token doesn't exist in memory or is expired, it should retrieve refresh token from persistent store and use it to obtain an access token from Keycloak.

We need to add support for offline tokens in Keycloak to support this idea. Otherwise admins have to re-link agents when the refresh token expires.

The benefits of this approach are:

* Very simple code in agents - just need to add a hard-coded string (token reference) to a header before invoking Hawkular
* No need to store username/password in agents (which would be the case if http basic was used)
* Users can revoke access to specific agents through account management

----- Original Message -----
> From: "Juraci Paixão Kröhling" <juraci at kroehling.de>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 27 May, 2015 10:40:19 AM
> Subject: Re: [keycloak-dev] Persistent token
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 05/27/2015 09:12 AM, Stian Thorgersen wrote:
> > To support "agents" or other non-humans we intend to add two things
> > to Keycloak:
> > 
> > * Client accounts - these are basically a account that's linked to
> > a specific client * Client auth mechanisms - cert and/or jwt/jws
> > auth mechanisms for clients
> > 
> > There's is standard flows in OpenID Connect for clients to
> > authenticate as themselves to retrieve tokens. We don't have this
> > yet though.
> 
> If there are plans on how to achieve that, I can help on this, as
> that's something we'd need on Hawkular.
> 
> > Do you want an agent to authenticate as itself, or on behalf of a
> > user? In either case for the time being you should use direct grant
> > to obtain a refresh token and store that. I would recommend you
> > create a small lib that makes it very easy for an agent to do that.
> > Something like (pseudo code, with no thoughts about usability):
> 
> On behalf of an user, so that we know under which account the data
> should be stored.
> 
> For the direct grant/token retrieval: let's split the issue in three
> parts. We have our own agent, then we might have third-party tools and
> finally we have custom collectors, written by sysadmins.
> 
> For our own agent, we can spend some time in "doing the right thing",
> including optimization of HTTP calls, secure storage of tokens and so
> on. So, even though it would be more complex than ideal, our agent is
> still under our control.
> 
> For third-party tools, we could provide libraries that would handle
> this part. We'd prefer not to, as this is maintenance cost that we
> might not be able to afford right now, specially we have to provide
> APIs for "all" major languages.
> 
> But for the sysadmins, we'd really need the simplest possible solution
> that works from the command line. The target here is to tell
> sysadmins: "here's a sample curl call that you could make", and let
> them do it. Having them worry about getting a token, parsing JSON and
> so on is something we are trying to avoid.
> 
> - - Juca.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVZYLzAAoJEDnJtskdmzLM23UH/0sK/o+1RdIx7JDEgxQmMcE6
> KmsxE72nkrbVbju3jjTn62h87L7TMpRH7w4qjVo3ekCdfN/Qd2D6FMpzAcIPaigM
> 7J9w5DH66Ibyj39sGynREjWvVWMDv5PV+79m3m22o1TNtkR5v9bzIhxsr749kpit
> p9GNJSLlorqRx8E0YtpGjEuoCo36NjdoW5kV3LnvO1iMiYJ3LxosnizrkWpBS0Sb
> RgSyxihB6vc2IL7+7DuxAOPSnb2tVmYyVYDB/WembpDExveVEDxJWv6yjR5mTGtd
> 7QPNUWTUGcnozjEeoiFXOP988+9RWfv1afCRhMjq7RFfbp8G9judjAY1kt+ly1U=
> =R815
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 



More information about the keycloak-dev mailing list