Basic auth should work with resource owner password credentials grant which I think is what Bill is talking about.  If it does not work, sending the user / pw as a form parameter in POST along with the other needed stuff definitely works.

from the RFC: http://tools.ietf.org/html/rfc6749#section-4.3
   The resource owner password credentials grant type is suitable in
   cases where the resource owner has a trust relationship with the
   client, such as the device operating system or a highly privileged
   application.  The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.

The only reason you wouldn't use this is if you don't trust your application with the credentials it needs to use.  By trying to get your app to go through the auth code flow without user interaction, I'm betting you are already embedding the credentials in your code.  If that is the case, I think using this is no less secure.

-Brian

Brian Cook
Principal Product Manager 
Ecosystem and Certification tools
407-212-7079

On Wed, Apr 27, 2016 at 9:46 AM, Aikeaguinea <aikeaguinea@xsmail.com> wrote:
Yes, we could do this -- my impression though was that the auth code
flow is considered more secure. (I admit I'm not entirely sure how the
Keycloak implicit grant flow differs from direct access grants --
whenever I look at OAuth documentation it just mentions the explicit and
implicit flows.)

On Wed, Apr 27, 2016, at 12:14 PM, Bill Burke wrote:
> Ues direct grants?
>
> On 4/27/2016 11:17 AM, Aikeaguinea wrote:
> > As I understand it, using the authorization code flow rather than the
> > implicit flow is recommended where possible.
> >
> > We have a server-side client application, but the user agents making
> > requests are not browsers, but instead our own code.
> >
> > I'm not entirely sure how to make the authorization code flow work
> > without a browser. For instance, if on the command line I request
> >
> > curl
> > 'http://host:port/auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri=http://www.example.com/hello-world'
> >
> > Then (assuming the parameters are correct) I get back an HTML login page
> > with a form. In order to submit the credentials, I would need to dig the
> > URL out of the action of the form and then submit a request like
> >
> > curl -X POST -d 'username=test-user' -d 'password=test1234'
> > 'http://host:port/auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b'
> >
> > Three questions:
> > 1. Is there some reason I shouldn't be trying to implement the
> > authorization code flow like this?
> >
> > 2. Is there a way to get the proper login action back without having to
> > dig it out of an HTML form? I've tried adding --header "Accept:
> > application/json" to the command but this has no effect.
> >
> > 3. Is there a way of submitting credentials other than by using form
> > parameters? I've tried HTTP basic auth but it doesn't work for me.
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


--
  Aikeaguinea
  aikeaguinea@xsmail.com

--
http://www.fastmail.com - Access all of your messages and folders
                          wherever you are

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user