[keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant
Nils Preusker
n.preusker at gmail.com
Tue Mar 11 09:48:01 EDT 2014
Hey Bill,
thanks for the clarification! We're also building a pure client side
JavaScript application which calls a bunch of stateless REST services. I'm
looking for the best way to secure those REST services and add a log-in
mechanism to the UI.
Now I looked at the new example customer-app-js which will be included in
the Alpha 3 release and saw that you are using bearer tokens there. So far,
I thought that the HttpOnly cookie mechanism was the preferred way to
handle OAuth in a pure client side app which uses stateless REST services.
In that scenario, I was just going to add a request interceptor in my JS
application, where I would handle unauthorized responses with either a
refresh token or a redirect to the log-in page. What do you think?
Cheers,
Nils
On Tue, Mar 11, 2014 at 2:14 PM, Bill Burke <bburke at redhat.com> wrote:
> The adapters do not set any cookies except the temporary OAUTH *state*
> cookie. The demo examples remember authenticated sessions by storing
> the token in the HttpSession.
>
> The admin console is really just a bunch of stateless REST services
> which is why it sets the Identity cookie. What you're seeing is a bug
> in Resteasy as the cookie is created with HttpOnly set to true.
>
> https://issues.jboss.org/browse/RESTEASY-1026
>
> On 3/11/2014 8:59 AM, Nils Preusker wrote:
> > digging a bit deeper... I looked for usages of HttpFacade.setCookie and
> > noticed that HttpOnly always seems to be set to false... If I understood
> > the log-in mechanism for pure client side JavaScript applications
> > correctly, it was supposed to be based on a HttpOnly cookie, which makes
> > it impossible for scripts (so the JavaScript application) to access the
> > cookie.
> >
> > Am I missing something?
> >
> > Cheers,
> > Nils
> >
> >
> > On Tue, Mar 11, 2014 at 12:08 PM, Nils Preusker <n.preusker at gmail.com
> > <mailto:n.preusker at gmail.com>> wrote:
> >
> > Hey guys,
> >
> > I just looked at the login mechanism and the communication between
> > the admin console and the backend in the alpha 2 release again. If
> > I'm not mistaken, you used to use HTTP-only for the
> > KEYCLOAK_SAAS_IDENTITY cookie. Did something change about that in
> > alpha 2? When I look at the HTTP requests in the chrome developer
> > console, I don't see the HttpOnly flag anywhere.
> >
> > Cheers,
> > Nils
> >
> >
> > On Thu, Jan 30, 2014 at 5:23 PM, Stian Thorgersen <stian at redhat.com
> > <mailto:stian at redhat.com>> wrote:
> >
> >
> >
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com <mailto:
> bburke at redhat.com>>
> > > To: keycloak-user at lists.jboss.org
> > <mailto:keycloak-user at lists.jboss.org>
> > > Sent: Thursday, 30 January, 2014 3:46:52 PM
> > > Subject: Re: [keycloak-user] Keycloak and OAuth 2.0 Resource
> > Owner Password Credentials Grant
> > >
> > >
> > >
> > > On 1/30/2014 9:29 AM, Nils Preusker wrote:
> > > > Hey Bill, thanks for the clarification, I didn't realize
> > that the cookie
> > > > was Http-only, neat!
> > > >
> > > > We are building a pure HTML5 client that is also hosted
> > separately from
> > > > the REST-backends. The thing is that we use a reverse proxy
> > so for the
> > > > browser it all looks like one app since everything comes
> > from different
> > > > paths in the same domain.
> > > >
> > > > I'll try to clarify the last part of my last mail: We are
> > currently
> > > > using
> >
> org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve
> > > > (skeleton-key-as7) in our REST-backend modules. If I'm not
> > mistaken,
> > > > some parts of the code base and concepts are the same as in
> > keycloak,
> > > > right?
> > > >
> > > > So far, in the AngularJS application we've been adding
> > bearer tokens to
> > > > the HTTP Authorization header. Since the backend uses
> > JAX-RS/ RestEasy,
> > > > the verification of the bearer tokens was done
> transparently by
> > > > OAuthAuthenticationServerValve and RESTEasy automatically
> > added the
> > > > roles etc. to the HttpServletRequest. Now in the REST
> > backend of the
> > > > admin app in keycloak you're doing the same thing
> > (validating the tokens
> > > > and extracting the roles) manually with the
> > AuthenticationManager
> > > > (authenticateSaasIdentityCookie(...)). So I was just
> > wondering whether
> > > > you are planning to make that process more transparent in
> > the future?
> > > >
> > >
> > > We're doing it manually because the original idea was that
> > the admin
> > > service could manage multiple organizations (a SaaS), so
> > you'd have to
> > > set up the cookie path's correctly.
> > >
> > > For your app, it sounds like @RolesAllowed will work. You
> > just have to
> > > set up the appropriate web.xml security constraints for your
> > REST urls
> > > in web.xml. Just set up the REST apis to require
> > authentication and let
> > > @RolesAllowed do the rest. The keycloak jboss/wildfly
> > adapter can
> > > handle BEARER token auth at the same time as regular browser
> > oauth. If
> > > the server is initiating the login, then you can just follow
> > the current
> > > keycloak examples. If not, then the Javascript lib Stian
> > wrote is an
> > > option (and something we'll have to document).
> >
> > JS lib needs a bit of work as well, if it's something you want I
> > can make it a priority
> >
> > >
> > >
> > >
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user at lists.jboss.org
> > <mailto:keycloak-user at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org <mailto:
> keycloak-user at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20140311/04259648/attachment.html
More information about the keycloak-user
mailing list