[keycloak-user] Authenticating non-interactive users

[Bill Burke]

We have a Direct grant REST API to obtain access/refresh token.  You 
have to enable it in the admin console.  Docs here:

http://docs.jboss.org/keycloak/docs/1.0.2.Final/userguide/html/direct-access-grants.html

I don't recommend transmitting refresh tokens.  They are supposed to 
stay local to the machine that requested the login.

On 10/10/2014 12:02 PM, Juraci Paixão Kröhling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> I'm assisting on a project that is about to implement Keycloak for
> user auth. They also need to authenticate/authorize non-interactive
> users (as in: nodes talking to a server) and are considering using
> Keycloak for that as well.
>
> My first thought was to use OAuth, performing the initial OAuth flow
> during the first boot of the server and then publishing the refresh
> token to the nodes, so that they can get bearer tokens whenever they
> need to talk to the server.
>
> While the above works in my PoC, it's not ideal:
> - - there has to be an unprotected resource, so that the node can get
> the refresh token
> - - the refresh token is related to the admin that first installed the
> server
> - - related to the above: auditing is harder, as the requests were
> appear to come from said admin
> - - node and server are the same application from the user's
> perspective, so, it makes no sense to have an "OAuth client" and an
> "Application" on Keycloak.
> - - having an extra code for the initial OAuth flow seems a bit counter
> productive
>
> There are some examples where part of this scenario could be covered,
> like the "KeycloakInstalled" from the integration project, but it also
> doesn't seems to quite fit into this.
>
> So, my questions would be:
>
> - - Would there be a better solution based on the latest Keycloak?
> - - If not, is this scenario something that would be interesting
> implementing?
>
> The advantage I see in having this implemented on Keycloak instead of
> baking a new solution is that the application wouldn't need to care if
> the request is coming from a non-interactive user or a real user, as
> long as the proper roles are set. Also, having one single auth
> mechanism for both non-interactive and interactive users is far better
> than mixing mechanisms based on the path.
>
> Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJUOAMvAAoJEDnJtskdmzLMf6cH/2LqY4owURTI3mMaw8n3U1Ws
> XARiU+QiXHeEaQ2BiMySIxHHZCC0kmi6z3eVv2Ku28daDjVUJmS+VlqLg7ogbt6J
> jUH1SHAWtEvcJu32SsxJOzKkFQcEndv/FThABBa8Z4KW91SgWJdSPYbGWKVOyc72
> XICPlD73l9zmnO4oJwr1oxy79pMbeX1/eiLox3ZgDgGwCKh/r5F8+LzhzPKWRWhM
> RkcGzwaIclTysBlYjx1RrFObrEs2oK4gQ2TBSvmIjurSQVs7xrwb78xzTqGOrU5a
> z7cInMQh5/4FJcFwRBKFjXQ8FcbyuLWTQ2elJsnD8VC2HTxRBecPKmD3Fa98WqM=
> =DWdv
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com