<div dir="ltr">Hi,<div><br></div><div>I looked at the admin console and examined the HTTP requests and redirects and, as far as I can see, you are using a cookie (KEYCLOAK_SAAS_COOKIE) to exchange the authentication information (OAuth token) between the JavaScript client app and the REST services. </div>
<div><br></div><div>Is there a specific reason you chose to use a cookie instead of a bearer token in an authorization header? </div><div><br></div><div>Also, are you planning to integrate the cookie mechanism as transparently as bearer tokens (transparently validating by configuring web.xml, adding user and roles to HttpServletRequest etc.)?</div>
<div><br></div><div>Cheers,</div><div>Nils</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 29, 2014 at 4:50 PM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 1/29/2014 10:32 AM, Nils Preusker wrote:<br>
> Hey, that all sounds pretty good! So far I was a bit reluctant to use a<br>
> third party login screen... But on second thought, the argument of being<br>
> able to add credential types over time without having to change your<br>
> application sounds pretty compelling.<br>
><br>
<br>
</div>Its not just that. Also each secured app gets "Forgot Password" "Lost<br>
Authenticator" for free. Admin console can also force users to change<br>
their password or update their authenticator.<br>
<div class="im"><br>
> Would you be interested in working together on a small AngularJS example<br>
> to showcase the integration of keycloak and client side web-applications?<br>
><br>
<br>
</div>We support this already. Keycloak Admin console is actually written in<br>
Angular JS. We have two flavors for client side web apps.<br>
<br>
* App's Server manages Keycloak interaction. Token is stored in the<br>
Http Session. Client can obtain token after authentication by a REST<br>
call to the App's Server. Keycloak Admin console uses this form.<br>
<br>
* Pure client side app. Stian has written a JS lib for this. basically<br>
performs all the same OAuth redirect protocol. Client (in addition to<br>
the user) is authenticated by checking/matching redirect URIs. This<br>
requires CORS set up though (which we also support).<br>
<br>
For CORS we only support "validated CORS" currently. The auth token<br>
contains the authorized origins which are validated on CORS requests.<br>
Next release we want the App's Server to query the Keycloak admin server<br>
for valid origins. This way you can make unauthenticated CORS requests<br>
which can sstill protect against XSS.<br>
<br>
We need to put an example and docs for all of this for the next release.<br>
<span class="HOEnZb"><font color="#888888"><br>
Bill<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>