<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 January 2016 at 23:14, 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">I was thinking that using direct grant from Browser Javascript would<br>
work with SSO if direct grant created and returned an SSO cookie and<br>
also checked to see if an SSO cookie was set. This way all the people<br>
wanting to completely bypass our login screens can do that. Why they<br>
would want to, I don't know. We maybe should extend the direct grant<br>
protocol to tell the client when required actions must be filled out<br>
before authentication, stuff like that.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</font></span></blockquote></div><br></div>