<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The current connect text follows this from the OAuth spec<div><br></div><div><span class="Apple-style-span" style="font-size: 16px; font-family: Times; "><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always; "> If requiring the
registration of the complete redirection URI is not possible, the
authorization server SHOULD require the registration of the URI
scheme, authority, and path (allowing the client to dynamically vary
only the query component of the redirection URI when requesting
authorization).
The authorization server MAY allow the client to register multiple
redirection endpoints.</pre></span><div><br></div><div>So should the Connect spec take the more strict approach of forcing an exact match including any query parameters.</div><div><br></div><div>If matching up to the query parameters only works with some IdP then we will have no end of interop issues.</div><div><br></div><div>If you force exact matching at the authz server why require the redirect_uri at the token endpoint?</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><div>On 2012-05-18, at 7:43 PM, Breno de Medeiros wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Fri, May 18, 2012 at 2:41 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br><blockquote type="cite">Justin,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What is your interpretation opt OAuth where:<br></blockquote><blockquote type="cite">1: the client registers multiple redirect_uri.<br></blockquote><blockquote type="cite">2: The client senda a redirect_uri in authz request with query paramaters.<br></blockquote><blockquote type="cite">3: The authz server matches the redirect URI with one of the registered ones up to the query string.<br></blockquote><blockquote type="cite">4: The client makes a request to the token endpoint without a redirect_uri<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Is this fine or an error.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">My reading of the OAuth Draft implies that this should return an error.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Though from a security point of view the authz server matching the first time should be sufficient.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thoughts?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This is needs to be clear for interop. If a client only registers one redirect_uri and simply sends a redirect_uri in the request to maintain some state in a query parameter, should it be forced to remember that parameter and sent it in the request to the token endpoint?<br></blockquote><br>There is no guarantee that adding a query parameter to a registered<br>URI will work. The Google authorization server rejects all<br>redirect_uris that don't match registered values, and compares them<br>exactly. Adding a query parameter to a redirect_uri will cause Google<br>to invalidate the request. That's fully compatible with OAuth2. That's<br>why OAuth2 defines a state parameter. The state parameter is not part<br>of the request to the token endpoint.<br><blockquote type="cite"><br></blockquote><blockquote type="cite">John B.<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Openid-specs-ab mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br></blockquote><blockquote type="cite"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></blockquote><blockquote type="cite"><br></blockquote><br><br><br>-- <br>--Breno<br></div></blockquote></div><br></div></body></html>