Hi,

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. 

Is there a specific reason you chose to use a cookie instead of a bearer token in an authorization header? 

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.)?

Cheers,
Nils


On Wed, Jan 29, 2014 at 4:50 PM, Bill Burke <bburke@redhat.com> wrote:


On 1/29/2014 10:32 AM, Nils Preusker wrote:
> Hey, that all sounds pretty good! So far I was a bit reluctant to use a
> third party login screen... But on second thought, the argument of being
> able to add credential types over time without having to change your
> application sounds pretty compelling.
>

Its not just that.  Also each secured app gets "Forgot Password" "Lost
Authenticator" for free.  Admin console can also force users to change
their password or update their authenticator.

> Would you be interested in working together on a small AngularJS example
> to showcase the integration of keycloak and client side web-applications?
>

We support this already.  Keycloak Admin console is actually written in
Angular JS.  We have two flavors for client side web apps.

* App's Server manages Keycloak interaction.  Token is stored in the
Http Session.  Client can obtain token after authentication by a REST
call to the App's Server.  Keycloak Admin console uses this form.

* Pure client side app.  Stian has written a JS lib for this.  basically
performs all the same OAuth redirect protocol.   Client (in addition to
the user) is authenticated by checking/matching redirect URIs.  This
requires CORS set up though (which we also support).

For CORS we only support "validated CORS" currently.  The auth token
contains the authorized origins which are validated on CORS requests.
Next release we want the App's Server to query the Keycloak admin server
for valid origins.  This way you can make unauthenticated CORS requests
which can sstill protect against XSS.

We need to put an example and docs for all of this for the next release.

Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user