[keycloak-dev] Keycloak.js is inefficient and can be improved
Stian Thorgersen
stian at redhat.com
Mon Feb 23 09:38:22 EST 2015
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 3:34:12 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
>
> Verifying the token would be a must for implicit flow, IMO. Not so much
> for access code flow though.
Should we add support for implicit flow?
>
> For access code flow it is not really possible to fool the javascript
> provider because of the "state" parameter, and obtaining an access token
> happens out of band.
We support passing tokens to keycloak.js to initialize it, but not sure if that could be exploited
>
> On 2/23/2015 9:26 AM, Stian Thorgersen wrote:
> > Looks pretty cool.
> >
> > I was wondering if we should verify the token in keycloak.js, not sure if
> > it's necessary, but if someone could pass an invalid token to keycloak.js
> > somehow they could potentially fool it into using it
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, February 9, 2015 11:51:04 PM
> >> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
> >>
> >> I had a good discussion on OAuth list about javascript and implicit flow
> >> vs. auth-code flow. It was pointed out that auth-code flow has some
> >> extra hops that can be avoided if you implement "response_mode=fragment".
> >>
> >> See this:
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-1033
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
More information about the keycloak-dev
mailing list