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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Aikeaguinea
aikeaguinea(a)xsmail.com
--
http://www.fastmail.com - Access all of your messages and folders
wherever you are
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user