[keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant

Nils Preusker n.preusker at gmail.com
Thu Jan 30 06:24:25 EST 2014


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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140130/cb36f0d2/attachment.html 


More information about the keycloak-user mailing list