[keycloak-user] Keycloak and AngularJS

[Bill Burke]

One of the problems with the keycloak.js approach is that we have no way 
to perform a single log out or to force a logout of a specific user.  I 
think the OpenID Connect spec may have a way with IFrames to do this 
sort of thing though.  I didn't really get it at first glance though.


On 3/27/2014 12:18 PM, Stian Thorgersen wrote:
> 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/
>>> client side JavaScript applications in keycloak?
>>> * 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
>> http://bill.burkecentral.com
>> _______________________________________________
>> 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