[keycloak-dev] Persistent token
Stian Thorgersen
stian at redhat.com
Wed May 27 03:12:34 EDT 2015
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.
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):
Auth auth = Auth.init("client-id", "client-secret", "username", "password");
String token = auth.getToken();
Under the covers this would invoke Keycloak's direct grant api to obtain a token. In the future when we add support for client account and client auth mechanisms it could be simplified to:
Auth auth = Auth.init("client-id", "client-secret");
or
X509Certificate cert = loadCert();
Auth auth = Auth.init("client-id", cert);
----- Original Message -----
> From: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 26 May, 2015 7:08:08 PM
> Subject: [keycloak-dev] Persistent token
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> All,
>
> For Hawkular, we have an agent that runs on behalf of an user on a
> separate machine (a server), sending metrics to our backend, secured
> by Keycloak.
>
> While we could perform all the OAuth steps in our agent code, a goal
> for us is to make it as easy as possible for third-parties to write
> "agents". So, having a basic-auth-like scenario is the ideal scenario
> for us.
>
> I think I have discussed this scenario earlier with Marek and/or Stian
> via IRC but I don't think a conclusion was made back then.
>
> Basically, what we would need is either a "persistent token" or a
> key/secret mechanism. For now, we are making the agent use the
> basic-auth, but that implies in the agent knowing the user's password
> (which is not ideal).
>
> As I understand that there were some talks about this before, I would
> like to understand what's the current (planned) solution for this
> scenario. Depending on how it goes, I can start with a PoC and send it
> as a PR for Keycloak.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVZKh4AAoJECKM1e+fkPrXdoUH/3DJty468AQ0MQgo5SokCrfu
> GvfGkDi0yMvOutsPdAYVGLxwUAFNFXICG1x/iP3UZYHcZgqzuclwMJQOV3/RKNAb
> uGn5VlllV5rhUnJiF49QeGVrYwB/O9llkRty5jzIzo0vej8eZl8LIQroxjIwpCEQ
> gy9OwBnj60mBcTvE33EgKKhAsBQ+aVKCFsc/LLDPxBljWvwk5o4OOwJ7HoqFoOI6
> Jh78ehOJam1cJug8U3wBWvf9VI2cZzxTAw5fUlM7YBwqR1ewiYsk2XrxQP7DTu76
> F0fYsi/fK2y8LA84K+QAztxXvOb5GiS/t6ZZAUER/ZkyzFUJ6qf908gwgqZKWA8=
> =dcGk
> -----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