<div dir="ltr">I appreciate this feature might be useful, so there's no need to discuss that aspect. The only issue I have with this PR is with regards to security and especially as it enables doing the "wrong" thing.<div><br></div><div>With regards to redirect URIs with confidential clients they are still important, but not quite as important as they are for public client. This means redirect URIs can typically be more flexible with confidential clients without a significant risk.</div><div><br></div><div>For public clients it's very important to lock these down as much as possible as they are the ONLY way to prevent malicious clients to gain access to the SSO session. This means we should actually tighten the requirements for redirect URIs not further relax them. For public clients the redirect URIs:</div><div><br></div><div>* Should be as specific as possible. We should only allow wildcard in the path. I believe we should introduce this for both public and confidential clients.</div><div>* Require HTTPs unless it's <a href="http://localhost">http://localhost</a>. This is not so easy in development, so maybe we should have an option to run the server in "unsafe" mode for developers.<br></div><div><br></div><div>Here's a quote from the OIDC spec around this:</div><div><br></div><div><i>"REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). The Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application."</i></div><div><i><br></i></div><div>Looking at your comments on the PR it worries me slightly that you have a shared client for a "library". A library is not a client. A client is an instance of an application. Sharing the client will have impact on audit, what clients a user believes they are authenticated to. With regards to wildcard to allow any subdomains that is scary as your allowing any piece of code running on any subdomain within your domain to authenticate via that particular client. That could be an infected forum, something any user has executing, etc.. As long as the redirect URI permits it an application can obtain a token for a client for a user that is authenticated without the user knowing about it. Unless you enable consent that is, but if the user used the "real" client they would have given consent and the malicious client on a different subdomain can take advantage of it.</div><div><br></div><div>In summary my opinion is that we can't accept this PR and that we further:</div><div><br></div><div>* Allow wildcard only in path. This is actually still looser than the OIDC spec mandates as it requires a simple string comparison.</div><div>* Require HTTPS (or custom scheme) for public clients. We may need a development mode that disables this.</div><div><br></div><div><i><br></i></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 September 2016 at 16:50, Josh Cain <span dir="ltr"><<a href="mailto:josh.cain@redhat.com" target="_blank">josh.cain@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Per <a rel="12650576" href="https://issues.jboss.org/browse/KEYCLOAK-3585" target="_blank">KEYCLOAK-3585:</a><p>Currently, valid redirect URI hostnames allow for wildcards at the end like so:</p>
<p>
</p><div style="border-width:1px;border-style:dashed;border-color:rgb(187,187,187);border-radius:5px;overflow:auto;max-height:30em">
<table style="font-size:1em;line-height:1.4em;font-weight:normal;font-style:normal;color:black" width="100%" border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="line-height:1.4em;padding:0em;vertical-align:top">
<pre style="font-size:1em;margin:10px;width:auto;padding:0px"><span style="color:black;font-family:"consolas","bitstream vera sans mono","courier new",courier,monospace"><a href="http://www.redhat.com/*" target="_blank">http://www.redhat.com/*</a>
</span></pre>
</td>
</tr>
</tbody>
</table>
</div>
<p>
</p><p>I'm managing several environments where clients need 'n' number of available redirect URI's with different hostnames, I.E.</p>
<p>
</p><div style="border-width:1px;border-style:dashed;border-color:rgb(187,187,187);border-radius:5px;overflow:auto;max-height:30em">
<table style="font-size:1em;line-height:1.4em;font-weight:normal;font-style:normal;color:black" width="100%" border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="line-height:1.4em;padding:0em;vertical-align:top">
<pre style="font-size:1em;margin:10px 10px 0px;width:auto;padding:0px"><span style="color:black;font-family:"consolas","bitstream vera sans mono","courier new",courier,monospace"><a href="http://developer1.env.redhat.com" target="_blank">http://developer1.env.redhat.<wbr>com</a></span></pre>
</td>
</tr>
<tr>
<td style="line-height:1.4em;padding:0em;vertical-align:top">
<pre style="font-size:1em;margin:0px 10px;width:auto;padding:0px"><span style="color:black;font-family:"consolas","bitstream vera sans mono","courier new",courier,monospace"><a href="http://developer2.env.redhat.com" target="_blank">http://developer2.env.redhat.<wbr>com</a></span></pre>
</td>
</tr>
<tr>
<td style="line-height:1.4em;padding:0em;vertical-align:top">
<pre style="font-size:1em;margin:0px 10px 10px;width:auto;padding:0px"><span style="color:black;font-family:"consolas","bitstream vera sans mono","courier new",courier,monospace"><a href="http://developer3.env.redhat.com" target="_blank">http://developer3.env.redhat.<wbr>com</a>
</span></pre>
</td>
</tr>
</tbody>
</table>
</div>
<p>
</p><p>Would really help to have the ability to wildcard hostnames too, I.E.:</p>
<p>
</p>
<pre style="font-size:1em;margin:10px;width:auto;padding:0px"><span style="color:black;font-family:"consolas","bitstream vera sans mono","courier new",courier,monospace">http://*.<a href="http://env.redhat.com" target="_blank">env.redhat.com</a>
</span></pre><br><div>I've submitted <a href="https://github.com/keycloak/keycloak/pull/3241" target="_blank">#3241</a> to address this issue, but there seem to be some concerns about allowing wildcards in other parts of the URL. See the PR for a more fleshed out discussion, but wanted to start a thread here on the mailing list. Particularly with respect to:<br><ul><li>Does anyone have need of this feature or would find it useful?</li><li>Should this kind of wildcard be allowed as a configuration option by Keycloak?<span class="HOEnZb"><font color="#888888"><br></font></span></li></ul></div><span class="HOEnZb"><font color="#888888"><div><div><div><div dir="ltr"><div><div dir="ltr"><span><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br><a href="tel:%2B1%20256-452-0150" value="+12564520150" target="_blank">+1 256-452-0150</a><br></span></div></div></div></div></div>
</div></font></span></div>
<br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>