<div dir="ltr">Hi Stian and Bill,<div><br></div><div>thanks for your replies! I'll check out the blog post and try the approach with a web.xml and a keycloak.json in the backend for now. I'll keep you posted on what I end up with on the client side.</div>
<div><br></div><div>Cheers,</div><div>Nils</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 27, 2014 at 5:18 PM, Stian Thorgersen <span dir="ltr"><<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Personally, I think that in most cases for a client-side web app the best approach is to let the client-side do the oauth flow (the approach we're currently taking in keycloak.js). It does depend on your application though, and if you're application has a strict one html5 app calls one REST service then http-only cookies are an option. I don't see any real benefits of it though, and I believe it significantly complicates things.<br>
<br>
Have a look at <a href="http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/" target="_blank">http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/</a>, I think it provides a good summary of the pros of the token approach.<br>
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
> From: "Bill Burke" <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>><br>
> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> Sent: Thursday, 27 March, 2014 3:39:07 PM<br>
> Subject: Re: [keycloak-user] Keycloak and AngularJS<br>
><br>
> What I like about the current admin console approach is that there is no<br>
> book keeping required by the browser. The Angular app has really no<br>
> knowledge of how it is being secured as its all driven by the server.<br>
> Also, you need to remember that the admin console was designed to be run<br>
> in a non-Java EE, non-servlet environment. While this is a requirement<br>
> for Keycloak, it may not be for your application. So, what I'm saying<br>
> is that for your angular application, you could rely on the servlet<br>
> container and keycloak adapter to maintain a session cookie and identity.<br>
><br>
> What I like about the keycloak.js approach is that there is no<br>
> server-side adapter required for the UI. The UI could be hosted off any<br>
> number of static web sites and use CORS invocations to any number of<br>
> Restful services.<br>
><br>
> There's also the debate of public vs. confidential clients. The<br>
> keycloak.js approach requires a public client. My understanding was<br>
> that confidential clients exist so that only an authenticated client<br>
> (client *NOT* user) is able to obtain an access token. I'm not exactly<br>
> sure what additional security benefits are obtained here beyond this.<br>
> I've been trying to ask this very question on OAuth mail lists but have<br>
> been unable to get a response so far.<br>
><br>
><br>
><br>
> On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
> > Hi Stian and Bill,<br>
> ><br>
> > I've posted some questions regarding this topic before but I thought I'd<br>
> > start a new thread to keep things focused:<br>
> ><br>
> > I'm writing an AngularJS application with Java EE 6/7 REST (JAX-RS)<br>
> > backend modules. To add authentication and authorization to this<br>
> > application, I'd like to use keycloak<br>
> ><br>
> > * as a user and role management front-end<br>
> > * to provide a customizable login page (works very well by the way ;)<br>
> > * as an OAuth 2.0 token provider<br>
> > * to add user and role information to the HTTPRequests in my REST/<br>
> > backend modules<br>
> ><br>
> > To do this, I'm currently looking at keycloak.js and the customer-app-js<br>
> > example. However, I'm wondering whether this is really the best way to<br>
> > go. In a reply to an earlier post of mine you mentioned that the<br>
> > keycloak admin console is written in AngularJS and that you are using<br>
> > HTTP-only cookies there.<br>
> ><br>
> > However, in keycloak.js and the customer-app-js example you are<br>
> > retrieving the token in the JS app and adding an authorization header<br>
> > with a bearer token to the HTTP requests.<br>
> ><br>
> > So here are my questions:<br>
> ><br>
> > * Is there a reason you are using two different approaches in the admin<br>
> > console and the official demo app?<br>
> > * which one of the two approaches (bearer tokens vs. HTTP-only cookie)<br>
> > will you support/ will be the officially recommended one for HTML5/<br>
> > client side JavaScript applications in keycloak?<br>
> > * am I right in assuming that you haven't quite decided yet which<br>
> > approach to use and that you are still discussing this in the keycloak<br>
> > team?<br>
> ><br>
> > Looking forwards to your reply!<br>
> > Cheers,<br>
> > Nils<br>
> ><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" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
><br>
> --<br>
> Bill Burke<br>
> JBoss, a division of Red Hat<br>
> <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><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" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</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" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>