[keycloak-dev] Persistent token

[Juraci Paixão Kröhling]

-----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-----