[keycloak-user] Authorization code flow without a browser

[Brian Cook]

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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
>   Aikeaguinea
>   aikeaguinea at xsmail.com
>
> --
> http://www.fastmail.com - Access all of your messages and folders
>                           wherever you are
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160427/c36f5e3a/attachment.html