<div dir="ltr">Cheers Bill, I added <div><br></div><div>KeycloakSecurityContext ctx = (KeycloakSecurityContext) servletRequest.getAttribute(KeycloakSecurityContext.class.getName());<br></div><div><br></div><div>and can now access the user name via ctx.getToken().getPreferredUsername().</div>
<div><br></div><div>The only downside to this is that I now need keycloak in my dependencies in irder to know the class KeycloakSecurityContext, but I guess I can live with that :)</div><div><br></div><div>Thanks again!</div>
<div>Nils</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 28, 2014 at 4:57 PM, Bill Burke <span dir="ltr">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The KeycloakSecurityContext has access to the IDToken which can contain<br>
information like name, email, address, etc... Depending on how you<br>
configure your realm.  Maybe IDToken should be added to the<br>
KeycloakPrincipal?<br>
<div><div class="h5"><br>
On 3/28/2014 11:47 AM, Stian Thorgersen wrote:<br>
&gt; Yes that is expected behaviour. The ID of the user is the unique reference to a user within Keycloak, and is what we recommend you use to refer to the user within your application when possible. The reason being is that there are reasons why a username/email may not refer to the same user over time. For example we will allow users to change their username (a feature you&#39;ll be able to disable), a user may be deleted, and another user re-created with the same username.<br>

&gt;<br>
&gt; ----- Original Message -----<br>
&gt;&gt; From: &quot;Nils Preusker&quot; &lt;<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a>&gt;<br>
&gt;&gt; To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt; Sent: Friday, 28 March, 2014 3:17:37 PM<br>
&gt;&gt; Subject: Re: [keycloak-user] Inject (Keycloak)Principal<br>
&gt;&gt;<br>
&gt;&gt; Hi all,<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m also looking into this right now and got it to work. However, I tried to<br>
&gt;&gt; retrieve the username from the HttpServletRequest with<br>
&gt;&gt; &quot;servletRequest.getRemoteUser()&quot; but instead of the name or e-mail I&#39;m<br>
&gt;&gt; getting the actual ID from the database<br>
&gt;&gt; (62ccf5fd-949b-413d-977b-6f8bc29f94bf).<br>
&gt;&gt;<br>
&gt;&gt; Is this the expected/ intended behavior?<br>
&gt;&gt;<br>
&gt;&gt; Also, @Dirk: let me know if you need any help getting the injection of the<br>
&gt;&gt; roles and user id to work.<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt; Nils<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Mar 28, 2014 at 8:16 AM, Juraci Paixão Kröhling &lt; <a href="mailto:juraci@kroehling.de">juraci@kroehling.de</a><br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt;&gt; Hash: SHA512<br>
&gt;&gt;<br>
&gt;&gt; Dirk,<br>
&gt;&gt;<br>
&gt;&gt; It seems it&#39;s missing the @SecurityDomain(&quot;keycloak&quot;) in your service,<br>
&gt;&gt; at the type level. If that&#39;s not the case, I can update the<br>
&gt;&gt; &quot;sample-ejb-roles&quot; quickstart, adapted to use Keycloak, so you can<br>
&gt;&gt; compare and check what&#39;s missing.<br>
&gt;&gt;<br>
&gt;&gt; Just to confirm: have you also added the security-domain to the<br>
&gt;&gt; standalone.xml? The instructions are at the end of section 6.2.1 from<br>
&gt;&gt; the user guide:<br>
&gt;&gt;<br>
&gt;&gt; <a href="http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/index.html#d4e485" target="_blank">http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/index.html#d4e485</a><br>
&gt;&gt;<br>
&gt;&gt; Juca.<br>
&gt;&gt;<br>
&gt;&gt; On 03/28/2014 01:31 AM, Dirk Franssen wrote:<br>
&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I was playing around with the examples, more specifically with the<br>
&gt;&gt;&gt; customer-portal-js which is accessing the database resource. In<br>
&gt;&gt;&gt; that CustomerService I was trying to get access to the Principal<br>
&gt;&gt;&gt; and trying to extend to return in addition the username of the<br>
&gt;&gt;&gt; logged-in user:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; @Path(&quot;customers&quot;) public class CustomerService {<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; @Inject Principal principal;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; //@Context //SecurityContext sc; //Principal principal =<br>
&gt;&gt;&gt; sc.getUserPrincipal();<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; //@Context //ContainerRequestContext request; //SecurityContext sc<br>
&gt;&gt;&gt; = request.getSecurityContext(); //Principal principal =<br>
&gt;&gt;&gt; sc.getUserPrincipal();<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; @GET @Produces(&quot;application/json&quot;) @NoCache public List&lt;String&gt;<br>
&gt;&gt;&gt; getCustomers() { ArrayList&lt;String&gt; rtn = new ArrayList&lt;String&gt;();<br>
&gt;&gt;&gt; rtn.add(&quot;Bill Burke&quot;); rtn.add(&quot;Stian Thorgersen&quot;); rtn.add(&quot;Stan<br>
&gt;&gt;&gt; Silvert&quot;); rtn.add(&quot;Gabriel Cardoso&quot;); rtn.add(&quot;Viliam Rockai&quot;);<br>
&gt;&gt;&gt; rtn.add(&quot;Marek Posolda&quot;); rtn.add(&quot;Boleslaw Dawidowicz&quot;);<br>
&gt;&gt;&gt; rtn.add(principal.getName()); //&lt;--- add username to the list<br>
&gt;&gt;&gt; return rtn; } }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; But this throws a npe as the principal is always null. I noticed<br>
&gt;&gt;&gt; that the JaxrsBearerTokenFilter is adding to the<br>
&gt;&gt;&gt; ContainerRequestContext a new SecurityContex, of which the<br>
&gt;&gt;&gt; getUserPrincipal method returns the KeycloakPrincipal. But I can&#39;t<br>
&gt;&gt;&gt; figure out how to get access to this from the CustomerService.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; My intention is to verify if the logged-in user is accessing his<br>
&gt;&gt;&gt; own resources, and e.g. is not trying to update data of somebody<br>
&gt;&gt;&gt; else. E.g. the id should match principal.getName() in following:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; @POST @Path(&quot;/users/{id}/friends&quot;) public void<br>
&gt;&gt;&gt; addFriend(@PathParam(&quot;id&quot;) String userId, Friend friend) { ... }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Any suggestions? It would be nice if, beside the KeycloakPrincipal<br>
&gt;&gt;&gt; is injectable, to be able to define something like @IsOwner:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; public void addFriend(@PathParam(&quot;id&quot;) @IsOwner String userId,<br>
&gt;&gt;&gt; Friend friend)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; or even more concise:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; public void addFriend(@IsOwner(&quot;id&quot;) String userId, Friend friend)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Kind regards, Dirk Franssen<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Thu, Mar 27, 2014 at 5:29 PM,<br>
&gt;&gt;&gt; &lt; <a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a> &gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Send keycloak-user mailing list submissions to<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; To subscribe or unsubscribe via the World Wide Web, visit<br>
&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a> or, via<br>
&gt;&gt;&gt; email, send a message with subject or body &#39;help&#39; to<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user-request@lists.jboss.org">keycloak-user-request@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; You can reach the person managing the list at<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user-owner@lists.jboss.org">keycloak-user-owner@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user-owner@lists.jboss.org">keycloak-user-owner@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; When replying, please edit your Subject line so it is more<br>
&gt;&gt;&gt; specific than &quot;Re: Contents of keycloak-user digest...&quot;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Today&#39;s Topics:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1. Re: Keycloak and AngularJS (Bill Burke) 2. Re: Keycloak and<br>
&gt;&gt;&gt; AngularJS (Stian Thorgersen) 3. Re: Keycloak and AngularJS (Nils<br>
&gt;&gt;&gt; Preusker) 4. Re: Keycloak and AngularJS (Bill Burke)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ----------------------------------------------------------------------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Message: 1 Date: Thu, 27 Mar 2014 11:39:07 -0400 From: Bill Burke<br>
&gt;&gt;&gt; &lt; <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &lt;mailto: <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &gt;&gt; Subject: Re:<br>
&gt;&gt;&gt; [keycloak-user] Keycloak and AngularJS To:<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt; Message-ID:<br>
&gt;&gt;&gt; &lt; <a href="mailto:5334461B.8040202@redhat.com">5334461B.8040202@redhat.com</a> &lt;mailto: <a href="mailto:5334461B.8040202@redhat.com">5334461B.8040202@redhat.com</a> &gt;&gt;<br>
&gt;&gt;&gt; Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What I like about the current admin console approach is that there<br>
&gt;&gt;&gt; is no book keeping required by the browser. The Angular app has<br>
&gt;&gt;&gt; really no knowledge of how it is being secured as its all driven by<br>
&gt;&gt;&gt; the server. Also, you need to remember that the admin console was<br>
&gt;&gt;&gt; designed to be run in a non-Java EE, non-servlet environment.<br>
&gt;&gt;&gt; While this is a requirement for Keycloak, it may not be for your<br>
&gt;&gt;&gt; application. So, what I&#39;m saying is that for your angular<br>
&gt;&gt;&gt; application, you could rely on the servlet container and keycloak<br>
&gt;&gt;&gt; adapter to maintain a session cookie and identity.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; What I like about the keycloak.js approach is that there is no<br>
&gt;&gt;&gt; server-side adapter required for the UI. The UI could be hosted<br>
&gt;&gt;&gt; off any number of static web sites and use CORS invocations to any<br>
&gt;&gt;&gt; number of Restful services.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There&#39;s also the debate of public vs. confidential clients. The<br>
&gt;&gt;&gt; keycloak.js approach requires a public client. My understanding<br>
&gt;&gt;&gt; was that confidential clients exist so that only an authenticated<br>
&gt;&gt;&gt; client (client *NOT* user) is able to obtain an access token. I&#39;m<br>
&gt;&gt;&gt; not exactly sure what additional security benefits are obtained<br>
&gt;&gt;&gt; here beyond this. I&#39;ve been trying to ask this very question on<br>
&gt;&gt;&gt; OAuth mail lists but have been unable to get a response so far.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
&gt;&gt;&gt;&gt; Hi Stian and Bill,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;ve posted some questions regarding this topic before but I<br>
&gt;&gt;&gt; thought I&#39;d<br>
&gt;&gt;&gt;&gt; start a new thread to keep things focused:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;m writing an AngularJS application with Java EE 6/7 REST<br>
&gt;&gt;&gt;&gt; (JAX-RS) backend modules. To add authentication and authorization<br>
&gt;&gt;&gt;&gt; to this application, I&#39;d like to use keycloak<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * as a user and role management front-end * to provide a<br>
&gt;&gt;&gt;&gt; customizable login page (works very well by the way ;) * as an<br>
&gt;&gt;&gt;&gt; OAuth 2.0 token provider * to add user and role information to<br>
&gt;&gt;&gt;&gt; the HTTPRequests in my REST/ backend modules<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; To do this, I&#39;m currently looking at keycloak.js and the<br>
&gt;&gt;&gt; customer-app-js<br>
&gt;&gt;&gt;&gt; example. However, I&#39;m wondering whether this is really the best<br>
&gt;&gt;&gt;&gt; way to go. In a reply to an earlier post of mine you mentioned<br>
&gt;&gt;&gt;&gt; that the keycloak admin console is written in AngularJS and that<br>
&gt;&gt;&gt;&gt; you are using HTTP-only cookies there.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; However, in keycloak.js and the customer-app-js example you are<br>
&gt;&gt;&gt;&gt; retrieving the token in the JS app and adding an authorization<br>
&gt;&gt;&gt;&gt; header with a bearer token to the HTTP requests.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; So here are my questions:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; * Is there a reason you are using two different approaches in<br>
&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt; admin<br>
&gt;&gt;&gt;&gt; console and the official demo app? * which one of the two<br>
&gt;&gt;&gt;&gt; approaches (bearer tokens vs. HTTP-only cookie) will you support/<br>
&gt;&gt;&gt;&gt; will be the officially recommended one for HTML5/ client side<br>
&gt;&gt;&gt;&gt; JavaScript applications in keycloak? * am I right in assuming<br>
&gt;&gt;&gt;&gt; that you haven&#39;t quite decided yet which approach to use and that<br>
&gt;&gt;&gt;&gt; you are still discussing this in the<br>
&gt;&gt;&gt; keycloak team?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Looking forwards to your reply! Cheers, Nils<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -- Bill Burke JBoss, a division of Red Hat<br>
&gt;&gt;&gt; <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ------------------------------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Message: 2 Date: Thu, 27 Mar 2014 12:18:01 -0400 (EDT) From: Stian<br>
&gt;&gt;&gt; Thorgersen &lt; <a href="mailto:stian@redhat.com">stian@redhat.com</a> &lt;mailto: <a href="mailto:stian@redhat.com">stian@redhat.com</a> &gt;&gt; Subject:<br>
&gt;&gt;&gt; Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke<br>
&gt;&gt;&gt; &lt; <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &lt;mailto: <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &gt;&gt; Cc:<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt; Message-ID:<br>
&gt;&gt;&gt; &lt; <a href="mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com">884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com">884719116.3009607.1395937081146.JavaMail.zimbra@redhat.com</a> &gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt; Content-Type: text/plain; charset=utf-8<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Personally, I think that in most cases for a client-side web app<br>
&gt;&gt;&gt; the best approach is to let the client-side do the oauth flow (the<br>
&gt;&gt;&gt; approach we&#39;re currently taking in keycloak.js). It does depend on<br>
&gt;&gt;&gt; your application though, and if you&#39;re application has a strict<br>
&gt;&gt;&gt; one html5 app calls one REST service then http-only cookies are an<br>
&gt;&gt;&gt; option. I don&#39;t see any real benefits of it though, and I believe<br>
&gt;&gt;&gt; it significantly complicates things.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Have a look at<br>
&gt;&gt;&gt; <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><br>
&gt;&gt;&gt; ,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt; I think it provides a good summary of the pros of the token approach.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ----- Original Message -----<br>
&gt;&gt;&gt;&gt; From: &quot;Bill Burke&quot; &lt; <a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &gt;&gt; To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt; Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:<br>
&gt;&gt;&gt;&gt; [keycloak-user] Keycloak and AngularJS<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; What I like about the current admin console approach is that<br>
&gt;&gt;&gt;&gt; there<br>
&gt;&gt;&gt; is no<br>
&gt;&gt;&gt;&gt; book keeping required by the browser. The Angular app has really<br>
&gt;&gt;&gt;&gt; no knowledge of how it is being secured as its all driven by the<br>
&gt;&gt;&gt;&gt; server. Also, you need to remember that the admin console was<br>
&gt;&gt;&gt;&gt; designed to<br>
&gt;&gt;&gt; be run<br>
&gt;&gt;&gt;&gt; in a non-Java EE, non-servlet environment. While this is a<br>
&gt;&gt;&gt; requirement<br>
&gt;&gt;&gt;&gt; for Keycloak, it may not be for your application. So, what I&#39;m<br>
&gt;&gt;&gt;&gt; saying is that for your angular application, you could rely on<br>
&gt;&gt;&gt;&gt; the servlet container and keycloak adapter to maintain a session<br>
&gt;&gt;&gt;&gt; cookie and<br>
&gt;&gt;&gt; identity.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; What I like about the keycloak.js approach is that there is no<br>
&gt;&gt;&gt;&gt; server-side adapter required for the UI. The UI could be hosted<br>
&gt;&gt;&gt; off any<br>
&gt;&gt;&gt;&gt; number of static web sites and use CORS invocations to any number<br>
&gt;&gt;&gt;&gt; of Restful services.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; There&#39;s also the debate of public vs. confidential clients. The<br>
&gt;&gt;&gt;&gt; keycloak.js approach requires a public client. My understanding<br>
&gt;&gt;&gt;&gt; was that confidential clients exist so that only an authenticated<br>
&gt;&gt;&gt;&gt; client (client *NOT* user) is able to obtain an access token.<br>
&gt;&gt;&gt;&gt; I&#39;m not<br>
&gt;&gt;&gt; exactly<br>
&gt;&gt;&gt;&gt; sure what additional security benefits are obtained here beyond<br>
&gt;&gt;&gt;&gt; this. I&#39;ve been trying to ask this very question on OAuth mail<br>
&gt;&gt;&gt;&gt; lists but<br>
&gt;&gt;&gt; have<br>
&gt;&gt;&gt;&gt; been unable to get a response so far.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
&gt;&gt;&gt;&gt;&gt; Hi Stian and Bill,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I&#39;ve posted some questions regarding this topic before but I<br>
&gt;&gt;&gt; thought I&#39;d<br>
&gt;&gt;&gt;&gt;&gt; start a new thread to keep things focused:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I&#39;m writing an AngularJS application with Java EE 6/7 REST<br>
&gt;&gt;&gt;&gt;&gt; (JAX-RS) backend modules. To add authentication and<br>
&gt;&gt;&gt;&gt;&gt; authorization to this application, I&#39;d like to use keycloak<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; * as a user and role management front-end * to provide a<br>
&gt;&gt;&gt;&gt;&gt; customizable login page (works very well by the<br>
&gt;&gt;&gt; way ;)<br>
&gt;&gt;&gt;&gt;&gt; * as an OAuth 2.0 token provider * to add user and role<br>
&gt;&gt;&gt;&gt;&gt; information to the HTTPRequests in my REST/ backend modules<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; To do this, I&#39;m currently looking at keycloak.js and the<br>
&gt;&gt;&gt; customer-app-js<br>
&gt;&gt;&gt;&gt;&gt; example. However, I&#39;m wondering whether this is really the<br>
&gt;&gt;&gt;&gt;&gt; best<br>
&gt;&gt;&gt; way to<br>
&gt;&gt;&gt;&gt;&gt; go. In a reply to an earlier post of mine you mentioned that<br>
&gt;&gt;&gt;&gt;&gt; the keycloak admin console is written in AngularJS and that you<br>
&gt;&gt;&gt;&gt;&gt; are<br>
&gt;&gt;&gt; using<br>
&gt;&gt;&gt;&gt;&gt; HTTP-only cookies there.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; However, in keycloak.js and the customer-app-js example you<br>
&gt;&gt;&gt;&gt;&gt; are retrieving the token in the JS app and adding an<br>
&gt;&gt;&gt;&gt;&gt; authorization<br>
&gt;&gt;&gt; header<br>
&gt;&gt;&gt;&gt;&gt; with a bearer token to the HTTP requests.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; So here are my questions:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; * Is there a reason you are using two different approaches in<br>
&gt;&gt;&gt; the admin<br>
&gt;&gt;&gt;&gt;&gt; console and the official demo app? * which one of the two<br>
&gt;&gt;&gt;&gt;&gt; approaches (bearer tokens vs. HTTP-only<br>
&gt;&gt;&gt; cookie)<br>
&gt;&gt;&gt;&gt;&gt; will you support/ will be the officially recommended one for<br>
&gt;&gt;&gt;&gt;&gt; HTML5/ client side JavaScript applications in keycloak? * am I<br>
&gt;&gt;&gt;&gt;&gt; right in assuming that you haven&#39;t quite decided yet which<br>
&gt;&gt;&gt;&gt;&gt; approach to use and that you are still discussing this in the<br>
&gt;&gt;&gt; keycloak<br>
&gt;&gt;&gt;&gt;&gt; team?<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Looking forwards to your reply! Cheers, Nils<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; -- Bill Burke JBoss, a division of Red Hat<br>
&gt;&gt;&gt;&gt; <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ------------------------------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Message: 3 Date: Thu, 27 Mar 2014 17:24:06 +0100 From: Nils<br>
&gt;&gt;&gt; Preusker &lt; <a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a> &lt;mailto: <a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a> &gt;&gt;<br>
&gt;&gt;&gt; Subject: Re: [keycloak-user] Keycloak and AngularJS To:<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt; Message-ID:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &lt;CA+HCLu_XG0xu+KUALgxoDuAMftA= <a href="mailto:rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com">rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt; &lt;mailto: <a href="mailto:rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com">rBgV-eFhwbDvaxq48NiOwQ@mail.gmail.com</a> &gt;&gt;<br>
&gt;&gt;&gt; Content-Type: text/plain; charset=&quot;iso-8859-1&quot;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi Stian and Bill,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; thanks for your replies! I&#39;ll check out the blog post and try the<br>
&gt;&gt;&gt; approach with a web.xml and a keycloak.json in the backend for now.<br>
&gt;&gt;&gt; I&#39;ll keep you posted on what I end up with on the client side.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cheers, Nils<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Thu, Mar 27, 2014 at 5:18 PM, Stian Thorgersen<br>
&gt;&gt;&gt; &lt; <a href="mailto:stian@redhat.com">stian@redhat.com</a> &lt;mailto: <a href="mailto:stian@redhat.com">stian@redhat.com</a> &gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Personally, I think that in most cases for a client-side web app<br>
&gt;&gt;&gt; the best<br>
&gt;&gt;&gt;&gt; approach is to let the client-side do the oauth flow (the<br>
&gt;&gt;&gt;&gt; approach<br>
&gt;&gt;&gt; we&#39;re<br>
&gt;&gt;&gt;&gt; currently taking in keycloak.js). It does depend on your<br>
&gt;&gt;&gt;&gt; application though, and if you&#39;re application has a strict one<br>
&gt;&gt;&gt;&gt; html5 app calls<br>
&gt;&gt;&gt; one REST<br>
&gt;&gt;&gt;&gt; service then http-only cookies are an option. I don&#39;t see any<br>
&gt;&gt;&gt;&gt; real<br>
&gt;&gt;&gt; benefits<br>
&gt;&gt;&gt;&gt; of it though, and I believe it significantly complicates things.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Have a look at<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt; <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><br>
&gt;&gt;&gt; ,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think it provides a good summary of the pros of the token<br>
&gt;&gt;&gt; approach.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ----- Original Message -----<br>
&gt;&gt;&gt;&gt;&gt; From: &quot;Bill Burke&quot; &lt; <a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
&gt;&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &gt;&gt; To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt; Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:<br>
&gt;&gt;&gt;&gt;&gt; [keycloak-user] Keycloak and AngularJS<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; What I like about the current admin console approach is that<br>
&gt;&gt;&gt; there is no<br>
&gt;&gt;&gt;&gt;&gt; book keeping required by the browser. The Angular app has<br>
&gt;&gt;&gt;&gt;&gt; really no knowledge of how it is being secured as its all<br>
&gt;&gt;&gt;&gt;&gt; driven by the<br>
&gt;&gt;&gt; server.<br>
&gt;&gt;&gt;&gt;&gt; Also, you need to remember that the admin console was designed<br>
&gt;&gt;&gt; to be run<br>
&gt;&gt;&gt;&gt;&gt; in a non-Java EE, non-servlet environment. While this is a<br>
&gt;&gt;&gt; requirement<br>
&gt;&gt;&gt;&gt;&gt; for Keycloak, it may not be for your application. So, what<br>
&gt;&gt;&gt;&gt;&gt; I&#39;m<br>
&gt;&gt;&gt; saying<br>
&gt;&gt;&gt;&gt;&gt; is that for your angular application, you could rely on the<br>
&gt;&gt;&gt;&gt;&gt; servlet container and keycloak adapter to maintain a session<br>
&gt;&gt;&gt;&gt;&gt; cookie and<br>
&gt;&gt;&gt; identity.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; What I like about the keycloak.js approach is that there is no<br>
&gt;&gt;&gt;&gt;&gt; server-side adapter required for the UI. The UI could be<br>
&gt;&gt;&gt;&gt;&gt; hosted<br>
&gt;&gt;&gt; off any<br>
&gt;&gt;&gt;&gt;&gt; number of static web sites and use CORS invocations to any<br>
&gt;&gt;&gt;&gt;&gt; number of Restful services.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; There&#39;s also the debate of public vs. confidential clients.<br>
&gt;&gt;&gt;&gt;&gt; The keycloak.js approach requires a public client. My<br>
&gt;&gt;&gt;&gt;&gt; understanding was that confidential clients exist so that only<br>
&gt;&gt;&gt;&gt;&gt; an authenticated client (client *NOT* user) is able to obtain<br>
&gt;&gt;&gt;&gt;&gt; an access token. I&#39;m not<br>
&gt;&gt;&gt; exactly<br>
&gt;&gt;&gt;&gt;&gt; sure what additional security benefits are obtained here<br>
&gt;&gt;&gt;&gt;&gt; beyond<br>
&gt;&gt;&gt; this.<br>
&gt;&gt;&gt;&gt;&gt; I&#39;ve been trying to ask this very question on OAuth mail lists<br>
&gt;&gt;&gt; but have<br>
&gt;&gt;&gt;&gt;&gt; been unable to get a response so far.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; Hi Stian and Bill,<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;ve posted some questions regarding this topic before but I<br>
&gt;&gt;&gt; thought<br>
&gt;&gt;&gt;&gt; I&#39;d<br>
&gt;&gt;&gt;&gt;&gt;&gt; start a new thread to keep things focused:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;m writing an AngularJS application with Java EE 6/7 REST<br>
&gt;&gt;&gt; (JAX-RS)<br>
&gt;&gt;&gt;&gt;&gt;&gt; backend modules. To add authentication and authorization to<br>
&gt;&gt;&gt;&gt;&gt;&gt; this application, I&#39;d like to use keycloak<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * as a user and role management front-end * to provide a<br>
&gt;&gt;&gt;&gt;&gt;&gt; customizable login page (works very well by the<br>
&gt;&gt;&gt; way ;)<br>
&gt;&gt;&gt;&gt;&gt;&gt; * as an OAuth 2.0 token provider * to add user and role<br>
&gt;&gt;&gt;&gt;&gt;&gt; information to the HTTPRequests in my REST/ backend modules<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; To do this, I&#39;m currently looking at keycloak.js and the<br>
&gt;&gt;&gt;&gt; customer-app-js<br>
&gt;&gt;&gt;&gt;&gt;&gt; example. However, I&#39;m wondering whether this is really the<br>
&gt;&gt;&gt; best way to<br>
&gt;&gt;&gt;&gt;&gt;&gt; go. In a reply to an earlier post of mine you mentioned that<br>
&gt;&gt;&gt;&gt;&gt;&gt; the keycloak admin console is written in AngularJS and that<br>
&gt;&gt;&gt;&gt;&gt;&gt; you<br>
&gt;&gt;&gt; are using<br>
&gt;&gt;&gt;&gt;&gt;&gt; HTTP-only cookies there.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; However, in keycloak.js and the customer-app-js example you<br>
&gt;&gt;&gt;&gt;&gt;&gt; are retrieving the token in the JS app and adding an<br>
&gt;&gt;&gt;&gt;&gt;&gt; authorization<br>
&gt;&gt;&gt; header<br>
&gt;&gt;&gt;&gt;&gt;&gt; with a bearer token to the HTTP requests.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; So here are my questions:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * Is there a reason you are using two different approaches<br>
&gt;&gt;&gt;&gt;&gt;&gt; in<br>
&gt;&gt;&gt; the admin<br>
&gt;&gt;&gt;&gt;&gt;&gt; console and the official demo app? * which one of the two<br>
&gt;&gt;&gt;&gt;&gt;&gt; approaches (bearer tokens vs. HTTP-only<br>
&gt;&gt;&gt; cookie)<br>
&gt;&gt;&gt;&gt;&gt;&gt; will you support/ will be the officially recommended one for<br>
&gt;&gt;&gt; HTML5/<br>
&gt;&gt;&gt;&gt;&gt;&gt; client side JavaScript applications in keycloak? * am I right<br>
&gt;&gt;&gt;&gt;&gt;&gt; in assuming that you haven&#39;t quite decided yet which approach<br>
&gt;&gt;&gt;&gt;&gt;&gt; to use and that you are still discussing this in the<br>
&gt;&gt;&gt; keycloak<br>
&gt;&gt;&gt;&gt;&gt;&gt; team?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Looking forwards to your reply! Cheers, Nils<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; -- Bill Burke JBoss, a division of Red Hat<br>
&gt;&gt;&gt;&gt;&gt; <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt; -------------- next part -------------- An HTML attachment was<br>
&gt;&gt;&gt; scrubbed... URL:<br>
&gt;&gt;&gt; <a href="http://lists.jboss.org/pipermail/keycloak-user/attachments/20140327/b8e5ee89/attachment-0001.html" target="_blank">http://lists.jboss.org/pipermail/keycloak-user/attachments/20140327/b8e5ee89/attachment-0001.html</a><br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; ------------------------------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Message: 4 Date: Thu, 27 Mar 2014 12:29:54 -0400 From: Bill Burke<br>
&gt;&gt;&gt; &lt; <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &lt;mailto: <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &gt;&gt; Subject: Re:<br>
&gt;&gt;&gt; [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen<br>
&gt;&gt;&gt; &lt; <a href="mailto:stian@redhat.com">stian@redhat.com</a> &lt;mailto: <a href="mailto:stian@redhat.com">stian@redhat.com</a> &gt;&gt; Cc:<br>
&gt;&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt; Message-ID:<br>
&gt;&gt;&gt; &lt; <a href="mailto:53345202.4060105@redhat.com">53345202.4060105@redhat.com</a> &lt;mailto: <a href="mailto:53345202.4060105@redhat.com">53345202.4060105@redhat.com</a> &gt;&gt;<br>
&gt;&gt;&gt; Content-Type: text/plain; charset=UTF-8; format=flowed<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; One of the problems with the keycloak.js approach is that we have<br>
&gt;&gt;&gt; no way to perform a single log out or to force a logout of a<br>
&gt;&gt;&gt; specific user. I think the OpenID Connect spec may have a way with<br>
&gt;&gt;&gt; IFrames to do this sort of thing though. I didn&#39;t really get it at<br>
&gt;&gt;&gt; first glance though.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 3/27/2014 12:18 PM, Stian Thorgersen wrote:<br>
&gt;&gt;&gt;&gt; Personally, I think that in most cases for a client-side web app<br>
&gt;&gt;&gt; the best approach is to let the client-side do the oauth flow (the<br>
&gt;&gt;&gt; approach we&#39;re currently taking in keycloak.js). It does depend on<br>
&gt;&gt;&gt; your application though, and if you&#39;re application has a strict<br>
&gt;&gt;&gt; one html5 app calls one REST service then http-only cookies are an<br>
&gt;&gt;&gt; option. I don&#39;t see any real benefits of it though, and I believe<br>
&gt;&gt;&gt; it significantly complicates things.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Have a look at<br>
&gt;&gt;&gt; <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><br>
&gt;&gt;&gt; ,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt; I think it provides a good summary of the pros of the token approach.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ----- Original Message -----<br>
&gt;&gt;&gt;&gt;&gt; From: &quot;Bill Burke&quot; &lt; <a href="mailto:bburke@redhat.com">bburke@redhat.com</a><br>
&gt;&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> &gt;&gt; To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt; Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:<br>
&gt;&gt;&gt;&gt;&gt; [keycloak-user] Keycloak and AngularJS<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; What I like about the current admin console approach is that<br>
&gt;&gt;&gt; there is no<br>
&gt;&gt;&gt;&gt;&gt; book keeping required by the browser. The Angular app has<br>
&gt;&gt;&gt;&gt;&gt; really no knowledge of how it is being secured as its all<br>
&gt;&gt;&gt;&gt;&gt; driven by the server. Also, you need to remember that the admin<br>
&gt;&gt;&gt;&gt;&gt; console was designed to<br>
&gt;&gt;&gt; be run<br>
&gt;&gt;&gt;&gt;&gt; in a non-Java EE, non-servlet environment. While this is a<br>
&gt;&gt;&gt; requirement<br>
&gt;&gt;&gt;&gt;&gt; for Keycloak, it may not be for your application. So, what<br>
&gt;&gt;&gt;&gt;&gt; I&#39;m<br>
&gt;&gt;&gt; saying<br>
&gt;&gt;&gt;&gt;&gt; is that for your angular application, you could rely on the<br>
&gt;&gt;&gt;&gt;&gt; servlet container and keycloak adapter to maintain a session<br>
&gt;&gt;&gt;&gt;&gt; cookie and<br>
&gt;&gt;&gt; identity.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; What I like about the keycloak.js approach is that there is no<br>
&gt;&gt;&gt;&gt;&gt; server-side adapter required for the UI. The UI could be<br>
&gt;&gt;&gt;&gt;&gt; hosted<br>
&gt;&gt;&gt; off any<br>
&gt;&gt;&gt;&gt;&gt; number of static web sites and use CORS invocations to any<br>
&gt;&gt;&gt;&gt;&gt; number of Restful services.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; There&#39;s also the debate of public vs. confidential clients.<br>
&gt;&gt;&gt;&gt;&gt; The keycloak.js approach requires a public client. My<br>
&gt;&gt;&gt;&gt;&gt; understanding was that confidential clients exist so that only<br>
&gt;&gt;&gt;&gt;&gt; an authenticated client (client *NOT* user) is able to obtain<br>
&gt;&gt;&gt;&gt;&gt; an access token. I&#39;m not<br>
&gt;&gt;&gt; exactly<br>
&gt;&gt;&gt;&gt;&gt; sure what additional security benefits are obtained here beyond<br>
&gt;&gt;&gt;&gt;&gt; this. I&#39;ve been trying to ask this very question on OAuth mail<br>
&gt;&gt;&gt;&gt;&gt; lists<br>
&gt;&gt;&gt; but have<br>
&gt;&gt;&gt;&gt;&gt; been unable to get a response so far.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On 3/27/2014 10:41 AM, Nils Preusker wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; Hi Stian and Bill,<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;ve posted some questions regarding this topic before but I<br>
&gt;&gt;&gt; thought I&#39;d<br>
&gt;&gt;&gt;&gt;&gt;&gt; start a new thread to keep things focused:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;m writing an AngularJS application with Java EE 6/7 REST<br>
&gt;&gt;&gt;&gt;&gt;&gt; (JAX-RS) backend modules. To add authentication and<br>
&gt;&gt;&gt;&gt;&gt;&gt; authorization to this application, I&#39;d like to use keycloak<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * as a user and role management front-end * to provide a<br>
&gt;&gt;&gt;&gt;&gt;&gt; customizable login page (works very well by the<br>
&gt;&gt;&gt; way ;)<br>
&gt;&gt;&gt;&gt;&gt;&gt; * as an OAuth 2.0 token provider * to add user and role<br>
&gt;&gt;&gt;&gt;&gt;&gt; information to the HTTPRequests in my REST/ backend modules<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; To do this, I&#39;m currently looking at keycloak.js and the<br>
&gt;&gt;&gt; customer-app-js<br>
&gt;&gt;&gt;&gt;&gt;&gt; example. However, I&#39;m wondering whether this is really the<br>
&gt;&gt;&gt;&gt;&gt;&gt; best<br>
&gt;&gt;&gt; way to<br>
&gt;&gt;&gt;&gt;&gt;&gt; go. In a reply to an earlier post of mine you mentioned that<br>
&gt;&gt;&gt;&gt;&gt;&gt; the keycloak admin console is written in AngularJS and that<br>
&gt;&gt;&gt;&gt;&gt;&gt; you are<br>
&gt;&gt;&gt; using<br>
&gt;&gt;&gt;&gt;&gt;&gt; HTTP-only cookies there.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; However, in keycloak.js and the customer-app-js example you<br>
&gt;&gt;&gt;&gt;&gt;&gt; are retrieving the token in the JS app and adding an<br>
&gt;&gt;&gt;&gt;&gt;&gt; authorization<br>
&gt;&gt;&gt; header<br>
&gt;&gt;&gt;&gt;&gt;&gt; with a bearer token to the HTTP requests.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; So here are my questions:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * Is there a reason you are using two different approaches<br>
&gt;&gt;&gt;&gt;&gt;&gt; in<br>
&gt;&gt;&gt; the admin<br>
&gt;&gt;&gt;&gt;&gt;&gt; console and the official demo app? * which one of the two<br>
&gt;&gt;&gt;&gt;&gt;&gt; approaches (bearer tokens vs. HTTP-only<br>
&gt;&gt;&gt; cookie)<br>
&gt;&gt;&gt;&gt;&gt;&gt; will you support/ will be the officially recommended one for<br>
&gt;&gt;&gt;&gt;&gt;&gt; HTML5/ client side JavaScript applications in keycloak? * am<br>
&gt;&gt;&gt;&gt;&gt;&gt; I right in assuming that you haven&#39;t quite decided yet which<br>
&gt;&gt;&gt;&gt;&gt;&gt; approach to use and that you are still discussing this in<br>
&gt;&gt;&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt; keycloak<br>
&gt;&gt;&gt;&gt;&gt;&gt; team?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Looking forwards to your reply! Cheers, Nils<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; -- Bill Burke JBoss, a division of Red Hat<br>
&gt;&gt;&gt;&gt;&gt; <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -- Bill Burke JBoss, a division of Red Hat<br>
&gt;&gt;&gt; <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ------------------------------<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; &lt;mailto: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> &gt;<br>
&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; End of keycloak-user Digest, Vol 3, Issue 14<br>
&gt;&gt;&gt; ********************************************<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________ keycloak-user<br>
&gt;&gt;&gt; mailing list <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;&gt;<br>
&gt;&gt; -----BEGIN PGP SIGNATURE-----<br>
&gt;&gt; Version: GnuPG v2.0.22 (GNU/Linux)<br>
&gt;&gt; Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
&gt;&gt;<br>
&gt;&gt; iQEcBAEBCgAGBQJTNSHcAAoJEDnJtskdmzLMHrYH/1D/vMgPxD0WUZ5KdIoD5Cow<br>
&gt;&gt; gb9fa+RZDQrpPxL1qKpqWJX3g1cKt8hQa1Xz7dX64G3/xcLUUkoJKkAtiJPysp75<br>
&gt;&gt; xbkdWV+RGQXDHuyZcS75xEXQlPaWt2cEVxdSXMalzfQPzVhq00FBbeJLirKLbYsY<br>
&gt;&gt; I2CIjJgCSQhmOrVfP5vUSdrwsLsd+TBXee4779YiOceSW16oG9Nfsa5gF1XJSNhi<br>
&gt;&gt; o2fZCEkoXhbTD7RXuhhrDWlFBCQOIgWf6FUHEAVKnXeIR5oey6U9hv1Z16Kd2Pll<br>
&gt;&gt; Pv8+LWlJjKMfkmrCQrVQvYSI/n64vxjikta2ByBdOPethsebqXO9oknbiPtjq6E=<br>
&gt;&gt; =TiWl<br>
&gt;&gt; -----END PGP SIGNATURE-----<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; keycloak-user mailing list<br>
&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; keycloak-user mailing list<br>
&gt;&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; keycloak-user mailing list<br>
&gt; <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
&gt;<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>
</div></div><a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></blockquote></div><br></div>