Public clients rely on the redirect uri to prevent malicious clients from obtaining a token via the SSO session. As there is no redirect uri in direct grant there would no longer be a mechanism to prevent malicious clients. I know there's some level of protection in CORS, but IMO that on its own is not sufficient. A public client should require both redirect uri and CORS protection if it wants to utilize the SSO session.

It would also be inconsistent with the OIDC spec. There's nothing there about using SSO with direct grant. SSO is only available via web redirect flows and there's good reasons for that.

On 15 January 2016 at 23:14, Bill Burke <bburke@redhat.com> wrote:
I was thinking that using direct grant from Browser Javascript would
work with SSO if direct grant created and returned an SSO cookie and
also checked to see if an SSO cookie was set.  This way all the people
wanting to completely bypass our login screens can do that. Why they
would want to, I don't know.  We maybe should extend the direct grant
protocol to tell the client when required actions must be filled out
before authentication, stuff like that.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev