<div dir="ltr">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.<div><br></div><div>from the RFC: <a href="http://tools.ietf.org/html/rfc6749#section-4.3">http://tools.ietf.org/html/rfc6749#section-4.3</a></div><div><div> The resource owner password credentials grant type is suitable in</div><div> cases where the resource owner has a trust relationship with the</div><div> client, such as the device operating system or a highly privileged</div><div> application. The authorization server should take special care when</div><div> enabling this grant type and only allow it when other flows are not</div><div> viable.</div></div><div><br></div><div>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.</div><div><br></div><div>-Brian</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div style="font-size:small">Brian Cook</div><div style="font-size:small">Principal Product Manager </div><div style="font-size:small">Ecosystem and Certification tools</div><div style="font-size:small">407-212-7079</div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 27, 2016 at 9:46 AM, Aikeaguinea <span dir="ltr"><<a href="mailto:aikeaguinea@xsmail.com" target="_blank">aikeaguinea@xsmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, we could do this -- my impression though was that the auth code<br>
flow is considered more secure. (I admit I'm not entirely sure how the<br>
Keycloak implicit grant flow differs from direct access grants --<br>
whenever I look at OAuth documentation it just mentions the explicit and<br>
implicit flows.)<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Apr 27, 2016, at 12:14 PM, Bill Burke wrote:<br>
> Ues direct grants?<br>
><br>
> On 4/27/2016 11:17 AM, Aikeaguinea wrote:<br>
> > As I understand it, using the authorization code flow rather than the<br>
> > implicit flow is recommended where possible.<br>
> ><br>
> > We have a server-side client application, but the user agents making<br>
> > requests are not browsers, but instead our own code.<br>
> ><br>
> > I'm not entirely sure how to make the authorization code flow work<br>
> > without a browser. For instance, if on the command line I request<br>
> ><br>
> > curl<br>
> > 'http://host:port/auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri=<a href="http://www.example.com/hello-world" rel="noreferrer" target="_blank">http://www.example.com/hello-world</a>'<br>
> ><br>
> > Then (assuming the parameters are correct) I get back an HTML login page<br>
> > with a form. In order to submit the credentials, I would need to dig the<br>
> > URL out of the action of the form and then submit a request like<br>
> ><br>
> > curl -X POST -d 'username=test-user' -d 'password=test1234'<br>
> > 'http://host:port/auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b'<br>
> ><br>
> > Three questions:<br>
> > 1. Is there some reason I shouldn't be trying to implement the<br>
> > authorization code flow like this?<br>
> ><br>
> > 2. Is there a way to get the proper login action back without having to<br>
> > dig it out of an HTML form? I've tried adding --header "Accept:<br>
> > application/json" to the command but this has no effect.<br>
> ><br>
> > 3. Is there a way of submitting credentials other than by using form<br>
> > parameters? I've tried HTTP basic auth but it doesn't work for me.<br>
> ><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Aikeaguinea<br>
<a href="mailto:aikeaguinea@xsmail.com">aikeaguinea@xsmail.com</a><br>
<br>
--<br>
<a href="http://www.fastmail.com" rel="noreferrer" target="_blank">http://www.fastmail.com</a> - Access all of your messages and folders<br>
wherever you are<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>