<div dir="ltr">Hi<div><br></div><div>There is something inconsistent in the OIDC core spec at this level, as in the hybrid flow :</div><div> - as Brian underlines the ID Token must contain a nonce claim, </div><div> - but on the other hand when generating the Auth request, <a href="https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest">https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest</a> says that Auth Request must be "made as defined in <a href="https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest">https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest</a>" (the Authorization code flow Auth Request), where it's said that the nonce is optional...</div><div><br></div><div>The hybrid flow implementations I've seen in the wild (and notably Azure AD default behaviour) use a nonce, though.</div><div><br></div><div>So yes, it'd be better to state explicitely that it's mandatory, IMHO.</div><div><br></div><div>Thanks,</div><div><br></div><div>Philippe</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 4, 2017 at 2:52 PM, Brian Campbell via Openid-specs-fapi <span dir="ltr"><<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</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"><div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I thought that `nonce` was required in Hybrid Flow, but is apparently not.<br></blockquote><br></span><a href="http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken" target="_blank">http://openid.net/specs/<wbr>openid-connect-core-1_0.html#<wbr>HybridIDToken</a> says that nonce is required in Hybrid Flow.<br><br></div>I'd always thought that nonce was required when an ID Token would be returned in the front channel. But a literal reading of the spec would suggest it is required with any of the response types that result in the implicit or hybrid flow. <br></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 11:47 PM, Nat Sakimura via Openid-specs-fapi <span dir="ltr"><<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good points.<br>
<br>
1. One-time use of `request_uri`<br>
<br>
By this, I meant that `request_uri` could be used only once against the authorization endpoint. I did not mean that the GET to `request_uri` value should fail for the second access. I understand that the text is ambiguous and needs to be clarified.<br>
<br>
2. Attacker re-registering the request object<br>
<br>
Now, as to the problem of the replay against the request object endpoint, the client needs to include a nonce.<br>
I thought that `nonce` was required in Hybrid Flow, but is apparently not.<br>
So, it needs to be stated.<br>
Once `nonce` is there, iss (client_id) + redirect_uri + nonce become globally unique.<br>
It will act as the unique identifier for the request object.<br>
The AS needs to check it to find if it has been used before.<br>
<br>
Unless the request object has `exp`, the AS has to maintain the state indefinitely, which is not practical.<br>
So, we also need to state that `exp` needs to be included and it should expire in a short period of time.<br>
<br>
With it, the request object endpoint can reasonably reject the replay.<br>
<br>
What do you think?<br>
<br>
Nat<br>
--<br>
PLEASE READ :This e-mail is confidential and intended for the<br>
named recipient only. If you are not an intended recipient,<br>
please notify the sender and delete this e-mail.<br>
<div><div class="m_-4858430116467668740h5"><br>
<br>
> -----Original Message-----<br>
> From: Openid-specs-fapi<br>
> [mailto:<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-boun<wbr>ces@lists.openid.net</a>] On Behalf Of Vladimir<br>
> Dzhuvinov via Openid-specs-fapi<br>
> Sent: Wednesday, August 2, 2017 4:22 PM<br>
> To: <a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid<wbr>.net</a><br>
> Subject: [Openid-specs-fapi] Ensuring one-time use of request JWTs registered<br>
> at the request JWT endpoint<br>
><br>
> It appears to me that one-time use of request objects registered by URI cannot<br>
> be guaranteed, unless read access to the request_uri is strictly limited to<br>
> the AS only.<br>
><br>
> Consider the following scenario:<br>
><br>
> 1. Client registers request object at request_uri, one-time GET policy is<br>
> enforced, but the URL is world readable.<br>
> 2. Malicious JS code in the browser GETs the request_uri 3. The authorization<br>
> request will fail due to invalid request_uri 4. The malicious JS code can still<br>
> re-register the request object as many times as it wants<br>
><br>
><br>
> The statement in 7.2 may also need to be revised then:<br>
><br>
> <a href="http://openid.net/specs/openid-financial-api-part-2.html#request" rel="noreferrer" target="_blank">http://openid.net/specs/openid<wbr>-financial-api-part-2.html#<wbr>request</a><br>
><br>
> > The request object needs to be signed for the client authentication<br>
> > and as the evidence of the client submitting the request object, which<br>
> > sometimes is called 'non-repudiation'.<br>
><br>
> If the request_uri is world readable, even if the AS takes measure to make<br>
> it hard to guess, the end-user / user agent will always be able to get it and<br>
> re-register it, which means the signature doesn't really hold as evidence of<br>
> the client submitting the request JWT.<br>
><br>
><br>
> Vladimir<br>
<br>
<br>
</div></div>______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid<wbr>.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-fapi</a><br>
</blockquote></div><br></div>
<br>
</div></div><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><br>______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
<br></blockquote></div><br></div>