[keycloak-user] Keycloak and AngularJS
stian at redhat.com
Thu Mar 27 12:18:01 EDT 2014
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.
Have a look at http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/, I think it provides a good summary of the pros of the token approach.
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-user at lists.jboss.org
> Sent: Thursday, 27 March, 2014 3:39:07 PM
> Subject: Re: [keycloak-user] Keycloak and AngularJS
> What I like about the current admin console approach is that there is no
> book keeping required by the browser. The Angular app has really no
> knowledge of how it is being secured as its all driven by the server.
> Also, you need to remember that the admin console was designed to be run
> in a non-Java EE, non-servlet environment. While this is a requirement
> for Keycloak, it may not be for your application. So, what I'm saying
> is that for your angular application, you could rely on the servlet
> container and keycloak adapter to maintain a session cookie and identity.
> What I like about the keycloak.js approach is that there is no
> server-side adapter required for the UI. The UI could be hosted off any
> number of static web sites and use CORS invocations to any number of
> Restful services.
> There's also the debate of public vs. confidential clients. The
> keycloak.js approach requires a public client. My understanding was
> that confidential clients exist so that only an authenticated client
> (client *NOT* user) is able to obtain an access token. I'm not exactly
> sure what additional security benefits are obtained here beyond this.
> I've been trying to ask this very question on OAuth mail lists but have
> been unable to get a response so far.
> On 3/27/2014 10:41 AM, Nils Preusker wrote:
> > Hi Stian and Bill,
> > I've posted some questions regarding this topic before but I thought I'd
> > start a new thread to keep things focused:
> > I'm writing an AngularJS application with Java EE 6/7 REST (JAX-RS)
> > backend modules. To add authentication and authorization to this
> > application, I'd like to use keycloak
> > * as a user and role management front-end
> > * to provide a customizable login page (works very well by the way ;)
> > * as an OAuth 2.0 token provider
> > * to add user and role information to the HTTPRequests in my REST/
> > backend modules
> > To do this, I'm currently looking at keycloak.js and the customer-app-js
> > example. However, I'm wondering whether this is really the best way to
> > go. In a reply to an earlier post of mine you mentioned that the
> > keycloak admin console is written in AngularJS and that you are using
> > HTTP-only cookies there.
> > However, in keycloak.js and the customer-app-js example you are
> > retrieving the token in the JS app and adding an authorization header
> > with a bearer token to the HTTP requests.
> > So here are my questions:
> > * Is there a reason you are using two different approaches in the admin
> > console and the official demo app?
> > * which one of the two approaches (bearer tokens vs. HTTP-only cookie)
> > will you support/ will be the officially recommended one for HTML5/
> > * am I right in assuming that you haven't quite decided yet which
> > approach to use and that you are still discussing this in the keycloak
> > team?
> > Looking forwards to your reply!
> > Cheers,
> > Nils
> > _______________________________________________
> > 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
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
More information about the keycloak-user