<div dir="ltr"><div dir="ltr"><div class="m_3224700157747700743gmail-wiki-content m_3224700157747700743gmail-comment-content">
<p>I firmly believe that that assumption ("that that nonce is always
required for Hybrid flows no matter where the id_token is returned
from") is <b>not correct</b>. </p>
<p>Things would have been simpler, if Connect had just made <code>nonce</code> mandatory for all authentication requests. But that's not the case. </p>
<p>The <code>nonce</code> parameter and claim are used to protect
against replay of an ID token. Direct replay or injection of an ID token
is only possible when returned from the Authorization Endpoint because
that flows through the browser via some sort of redirection. When an ID
token is returned from the Token Endpoint, it's over a direct HTTPS
connection between client and server and there's no opportunity for
replay or injection of an ID token. There is opportunity there for
replay or injection of the authorization code but there are other
protections for that including one time use of the code and redirect_uri
checking on the access token request. That was the logic underlying <code>nonce</code>
being required for ID tokens when returned from the Authorization
Endpoint and optional for ID tokens when returned from the Token
Endpoint (and in turn when it is required on the authentication
request). That's why nonce is required for OIDC implicit flow (ID token
returned from the Authorization Endpoint) and optional for OIDC code
flow (ID token returned from the Token Endpoint). Consistent with that,
for hybrid it depends on the <code>response_type</code> with <code>code id_token</code> or <code>code id_token token</code> requiring nonce while it's optional for <code>code token</code>. </p>
<p>Both Connect Core 3.3.2.11 and 3.3.2.12 are about the hybrid flow
where ID tokens when returned from the Authorization Endpoint. Which is
what the text "apply to an ID Token returned from the Authorization
Endpoint" and "the contents of an ID Token returned from the
Authorization Endpoint" says. Whereas 3.3.3.6 and 3.3.3.7 are about ID
tokens when returned from the Token Endpoint. </p>
<p>Changing Core so that nonce is always required for Hybrid flows no
matter where the id_token is returned from would be a breaking change,
which really isn't okay for an errata. </p>
<p>Per spec, our AS/OP implementation only requires <code>nonce</code> on authentication requests that have a <code>response_type</code> that contains <code>id_token</code>
and would result in an ID token returned from the Authorization
Endpoint. It's worked that way, per spec, since 2013. And it was OpenID
Certified as a Hybrid OP (and other profiles) in in 2015. </p>
<p><a href="https://github.com/rohe/oidctest/issues/111#issuecomment-426450954" rel="nofollow" class="m_3224700157747700743gmail-ap-connect-link" target="_blank">https://github.com/rohe/oidctest/issues/111#issuecomment-426450954</a>
is indicative of an issue with the test suite. Which, if not fixed,
puts us in the very bad position of having to introduce a breaking
change to product in-order to re-certify.</p><p>[note: the above was copied from a comment made on <a href="https://bitbucket.org/openid/connect/issues/1052">Issue #1052</a>]<br></p>
</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 5:47 PM Hans Zandbelt via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">New issue 1052: make clear that nonce is always required for Hybrid flows<br>
<a href="https://bitbucket.org/openid/connect/issues/1052/make-clear-that-nonce-is-always-required" rel="noreferrer" target="_blank">https://bitbucket.org/openid/connect/issues/1052/make-clear-that-nonce-is-always-required</a><br>
<br>
Hans Zandbelt:<br>
<br>
Assuming that that `nonce` is always required for Hybrid flows no matter where the `id_token` is returned from, also following: <br>
<a href="https://github.com/rohe/oidctest/issues/111#issuecomment-426450954" rel="noreferrer" target="_blank">https://github.com/rohe/oidctest/issues/111#issuecomment-426450954</a><br>
<br>
In section 3.3.2.11. ID Token for the Core spec, <a href="https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken" rel="noreferrer" target="_blank">https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken</a>, it describes the ID token in the Hybrid flow, which says<br>
<br>
> When using the Hybrid Flow, these additional requirements for the following ID Token<br>
> Claims apply to an ID Token returned from the Authorization Endpoint:<br>
<br>
Since an ID Token may also be returned from the Token Endpoint, that sentence seems to be too restrictive and the last part "returned from the Authorization Endpoint" should be removed.<br>
<br>
FWIW: this may be a left-over from<br>
<br>
> 3.3.2.12. ID Token Validation<br>
<br>
where ID token validation is discussed for an `id_token` returned from the Authorization Endpoint, as opposed to:<br>
<br>
> 3.3.3.7. ID Token Validation<br>
<br>
where ID token validation is discussed for an `id_token` returned from the Token Endpoint.<br>
<br>
OTOH: if section 3.3.2.11. is only about ID tokens returned from the Authorization Endpoint and it is supposed to be the counterpart of <br>
<br>
> 3.3.3.6. ID Token<br>
<br>
where validation of the contents of an ID Token returned from the Token Endpoint is discussed, then the following should be added to the latter:<br>
<br>
> Use of the nonce Claim is REQUIRED for this flow.<br>
<br>
otherwise it is not clear that `nonce` is always required in Hybrid flows no matter where the ID token is returned from.<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>
<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>