<html><head></head><body bgcolor="#FFFFFF"><div>According to OAuth and Connect If there are redirect URI registered, they must match up to but not including the query parameters.</div><div><br></div><div>In OAuth all public clients MUST register redirect URI.</div><div><br></div><div>What you are proposing is insecure and violates the spec.</div><div><br></div><div>The OAuth spec requires that if a redirect URI was sent in the authorization request, the same URI needs to be sent to the token endpoint, and the Token endpoint must check that they are exactly the same.</div><div><br></div><div>I think that the OAuth spec was probably trying to say that if the authorization request redirect URI did not match a registered redirect URI then the client must send the redirect URI and the server must exactly match it with the one in the original request.</div><div><br></div><div>That may have been too complicated so they made it mandatory for the token endpoint to always check.</div><div><br></div><div>We are not trying to do anything different from OAuth though it looks like people are reading that requirement from the core spec differently. That my be an OAuth problem.</div><div><br></div><div>John B.<br>Sent from my iPad</div><div><br>On 2012-05-18, at 12:07 PM, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
There are several cases where you can't know the full redirect URI
ahead of time, not the least of which is when you've got some
application-specific query parameters that need to get added to the
callback in order to route to the right page on the return. Not
everybody can set up clean-looking path-only URLs in their
environments. While ideally you'd use the state parameter to sync up
any dynamic information with a stored environment, it's not always
convenient, and it doesn't always save you from using query
components anyway.<br>
<br>
The current language of "MUST for implicit" and "SHOULD for code"
makes the most sense to me, with the two stage checks. The logic
goes like this:<br>
<br>
[IdP/Authz Endpoint]:<br>
does RP have any registered redirect uris?<br>
- if yes: <br>
did the RP send a redirect uri with the request?<br>
- if yes:<br>
check sent value against registered values, assure
prefix match<br>
- if no:<br>
use "default" redirect if available; otherwise, error<br>
- if no:<br>
did the RP send a redirect uri with the request?<br>
- if yes:<br>
use this redirect uri; warn the user that the redirect
uri isn't verified at all<br>
- if no:<br>
error<br>
<br>
[IdP/Token Endpoint]:<br>
did the RP send a redirect uri in the Authz request?<br>
- if yes: <br>
did the RP send a redirect uri with the token request?<br>
- if yes:<br>
do exact string matching against these two values, query
and all<br>
- if no:<br>
error<br>
- if no:<br>
did the RP send a redirect uri with the token request?<br>
- if yes:<br>
error (?)<br>
- if no:<br>
OK<br>
<br>
It's true that this might need to be unwound a little bit from the
language in the spec, but these are the state machines as I see them
in OAuth2, and I see no reason for Connect to further restrict these
use cases.<br>
<br>
-- Justin<br>
<br>
On 05/17/2012 06:00 PM, John Bradley wrote:
<blockquote cite="mid:6A2F1D77-7B35-4D94-87B4-E7A2803C22A4@ve7jtb.com" type="cite">They added the redirect_uri checking to the token
endpoint to make it safe for code (I suspect that many sites won't
do it because they don't understand why it is required), but i
don't know what if any use cases there are for having a dynamic
path on the redirect_uri and how the client would keep track of it
to be able to send exactly that URI as the parameter to the token
endpoint.
<div><br>
</div>
<div>Perhaps Chuck or Justin will remember.</div>
<div><br>
</div>
<div>John </div>
<div>On 2012-05-17, at 5:46 PM, Nat Sakimura wrote:
<div><br class="Apple-interchange-newline">
<blockquote type="cite">So, the real question is, what kind of
use cases do we really throw away if we require the urls to
be registered. If my assumption that OAuth WG decided that
there are such use cases was bogus, then I am OK with MUST.
<div>
<br>
</div>
<div><br>
<br>
<div class="gmail_quote">On Fri, May 18, 2012 at 6:39 AM,
John Bradley <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">You don't need to
register the query parameters.
<div><br>
</div>
<div>I am OK with SHOULD for the code flow, however
for 'code token' it allows a 3rd party to get an
access token for someone else. </div>
<div><br>
</div>
<div>The attacker would then replay it with the code
at the real RP. With the removal of checking
nonce in the id_token you now have a great attack.</div>
<div><br>
</div>
<div>To safely use 'code id_token' you need to check
nonce or you are screwed as they say if the
redirect_uri is unregistered.</div>
<div><br>
</div>
<div>The way that the code flow on it's own gets
around it is by the check of the redirect_uri in
the authorization request with the one sent in the
token request the server is responsible for the
check in that case.</div>
<div><br>
</div>
<div>I suppose we could have the client retrieve
token and reject the id_token if code is invalid.
that however is a touch complicated.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span>
<div>
<span class="HOEnZb"><font color="#888888">John</font></span>
<div>
<div class="h5"><br>
<div>
<div>On 2012-05-17, at 5:13 PM, Nat Sakimura
wrote:</div>
<br>
<blockquote type="cite">My understanding was
that OAuth 2.0 allowed it to be SHOULD to
accommodate some use cases such as dynamic
return_to urls, etc. <br>
<br>
<div class="gmail_quote">On Fri, May 18,
2012 at 5:46 AM, John Bradley <span dir="ltr"><<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">We
are requiring registration, under
what circumstances would a client
not know it's return_to?
<div>
<br>
</div>
<div>It might be a custom scheme,
but that should be known in
advance.</div>
<span><font color="#888888">
<div><br>
</div>
<div>John</div>
</font></span>
<div>
<div>
<div><br>
<div>
<div>On 2012-05-17, at 4:03
PM, Nat Sakimura wrote:</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF">
<div>I think we should
keep SHOULD here. </div>
<div>There are use cases
that a MUST cannot be
fulfilled. <br>
<br>
=nat via iPhone</div>
<div><br>
On 2012/05/18, at
4:57, Chuck Mortimore
<<a moz-do-not-send="true" href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>>
wrote:<br>
<br>
</div>
<div><span></span></div>
<blockquote type="cite">
<div>
<div>Agreed. </div>
<div><br>
</div>
<div>It was
basically pointing
out that we were
over ridding the
OAuth language and
turning SHOULD to
MUST. As a
platform, we're ok
with it, as we're
on the MUST side
of things.</div>
<div><br>
</div>
<div>-cmort</div>
<div><br>
</div>
<br>
<div>
<div>On May 17,
2012, at 12:51
PM, John Bradley
wrote:</div>
<br>
<blockquote type="cite">
<div style="word-wrap:break-word">
We may have
been a bit
overzealous
with the MUST.
It should be
a MUST for
implicit and a
SHOULD for
code.
<div><br>
</div>
<div>From 10.6
of OAuth</div>
<div><br>
</div>
<div><span style="font-size:16px;font-family:Times">
<pre style="font-size:1em;margin-top:0px;margin-bottom:0px"> The authorization server
MUST require public clients and SHOULD require confidential clients
to register their redirection URIs. If a redirection URI is provided
in the request, the authorization server MUST validate it against the
registered value.</pre>
</span>
<div><br>
</div>
<div><br>
</div>
<div>I don't
the think we
are actually
precluded from
making the
SHOULD a must
for Connect.</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<div>
<div>On
2012-05-17, at
2:49 PM, Mike
Jones wrote:</div>
<br>
<blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">Hi
Chuck,</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">I
was going
through some
of my mail
working on
closing the
remaining
issues to
finish the
OAuth Bearer
RFC and I ran
across this
message, which
I realized
that I never
responded to.</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">Could
you expand on
“This violates
OAuth”? Is
there a change
you’d
recommend in
the Connect
specs as a
result?</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">(The
second point
is now moot,
as we decided
to remove the
Check ID
Endpoint at
the last
in-person
working group
meeting.)</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">
Thanks,</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">
-- Mike</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span>Chuck
Mortimore
[mailto:<a moz-do-not-send="true" href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>]<span> </span><br>
<b>Sent:</b><span> </span>Friday,
March 02, 2012
11:13 AM<br>
<b>To:</b><span> </span>Mike
Jones<br>
<b>Subject:</b><span> </span>Additional
issues/questions
with Basic</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"> </div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">
2.2.1
redirect_uri:
A redirection
URI where the
response will
be sent. This
MUST be
pre-registered
with the
provider.</div>
</div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">
</div>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">This
Violates OAuth</div>
</div>
</blockquote>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"> </div>
</div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">
</div>
</div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">2.3.1
CheckID:
access_token:
REQUIRED. The
ID Token
obtained from
an OpenID
Connect
Authorization
Request.</div>
</div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif"> </div>
</div>
<blockquote style="margin-left:30pt;margin-right:0in">
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">Why
is this the ID
Token, but
called
access_token?</div>
</div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">
</div>
</div>
<div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times
New
Roman',serif">Why
would we use
POST if it's
in an AuthZ
header?</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" style="color:blue;text-decoration:underline" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:blue;text-decoration:underline" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div>
</span></blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Openid-specs-ab
mailing list</span><br>
<span><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br><span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></body></html>