<html><head></head><body>What about <br>
<br>
<a href="http://tools.ietf.org/html/rfc6749#section-10.5">http://tools.ietf.org/html/rfc6749#section-10.5</a><br>
<br>
second paragraph, last sentence? <br>
<br>
We explicitly added this statement/requirement in order to address the specific risk associated with code theft when OAuth is used for authentication.<br><br><div class="gmail_quote"><br>
<br>
Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hi John, hi guys,<br /><br />It looks like my previous email didn't get through.<br /><br />The current OIDC spec doesn't actually relax the TLS requirement in<br />regard to the redirection endpoint:<br /><br /><a href="http://tools.ietf.org/html/rfc6749#section-3.1.2.1">http://tools.ietf.org/html/rfc6749#section-3.1.2.1</a><br /><br /><a href="http://3.1.2.1">3.1.2.1</a>. [Redirection] Endpoint Request Confidentiality<br /><br />The redirection endpoint SHOULD require the use of TLS as described<br />in Section 1.6 when the requested response type is "code" or "token",<br />or when the redirection request will result in the transmission of<br />sensitive credentials over an open network.  This specification does<br />not mandate the use of TLS because at the time of this writing,<br />requiring clients to deploy TLS is a significant hurdle for many<br />client developers.  If TLS is not available, the authorization server<br />SHOULD warn the resource ow
 ner
about the insecure endpoint prior to<br />redirection (e.g., display a message during the authorization<br />request).<br /><br />So we're actually fine with that.<br /><br /><br />This is the OIDC core redirect_uri spec for the "code" flow:<br /><br /><a href="http://openid.bitbucket.org/openid-connect-core-1_0.html#AuthorizationRequest">http://openid.bitbucket.org/openid-connect-core-1_0.html#AuthorizationRequest</a><br /><br />redirect_uri<br />REQUIRED. .... When using this flow, the Redirection URI MAY use the<br />http scheme, provided that the Client Type is confidential, as defined<br />in Section 2.1 of OAuth 2.0; otherwise, it MUST use the https scheme. <br />state<br /><br /><br />And here for the "implicit" flow:<br /><br /><a href="http://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest">http://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest</a><br /><br />redirect_uri<br />REQUIRED. ... When using this
  flow,
the Redirection URI MUST NOT use<br />the http scheme unless the Client is a native application, in which case<br />it MAY use the http: scheme with localhost as the hostname. <br /><br /><br />--<br />Vladimir Dzhuvinov : <a href="http://www.NimbusDS.com">www.NimbusDS.com</a> : vladimir@nimbusds.com<br /><br /><br /><br />-------- Original Message --------<br />Subject: Re: Whether to allow http redirection URIs for confidential<br />clients<br />From: John Bradley <ve7jtb@ve7jtb.com><br />Date: Thu, October 24, 2013 7:54 pm<br />To: Mike Jones <Michael.Jones@microsoft.com><br />Cc: Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com>,<br />"openid-specs-ab@lists.openid.net" <openid-specs-ab@lists.openid.net><br /><br />Sorry yes it went back and forth.  <br /><br />The question is if we should override the OAuth RFC's requirement for<br />TLS on the client in favour of allowing adoption of connect by those web<br />sites that don't implement TLS for
  login
and session cookies.<br /><br /><br />If a site has no TLS and can have it's cookies and passwords leaked,<br />then Connect without TLS is arguably no worse than the current situation<br />and arguably better because at-least the user is not leaking the<br />password.<br /><br /><br />So do we allow the bad thing to prevent the worse thing?<br /><br /><br />This makes code more likely to leak, and there is no real protection<br />possible other than using a hmac of the device fingerprint as the nonce,<br />but a TLS cert for the client is much simpler.<br /><br /><br />John B.<br /><br />On 2013-10-24, at 11:37 AM, Mike Jones <Michael.Jones@microsoft.com><br />wrote:<br /><br />John, you wrote: “At the IIW F2F we took a decision that we should<br />match the RFC and require the client to have a TLS endpoint if using a<br />http redirect.(not a custom scheme)”.  While the working group was<br />leaning that way early in the discussion, Naveen and others pushed back,
 <br
/>and that doesn’t actually match the decision that we recorded in the<br />notes, which say:<br />OP may prevent registration of redirect_uris that do not use<br />https<br />A confidential client needs to be required to use http<br />We will discuss this further on the list<br /><br />Consider this the start of the further discussion on the list.  What do<br />people think?<br /><br />-- Mike<br /><br />From: openid-specs-ab-bounces@lists.openid.net<br />[mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of John<br />Bradley<br />Sent: Thursday, October 24, 2013 5:42 AM<br />To: Vladimir Dzhuvinov / NimbusDS<br />Cc: openid-specs-ab@lists.openid.net<br />Subject: Re: [Openid-specs-ab] First Release Candidates for final OpenID<br />Connect specifications<br /><br /><br /><br />Snip<br />On 2013-10-24, at 1:36 AM, "Vladimir Dzhuvinov / NimbusDS"<br /><vladimir@nimbusds.com> wrote:<br /><br /><br /><br /><br /><br /><br />"When using this flow, the redirection
  URI
MAY use the http scheme,<br />provided that the Client Type is confidential, as defined in Section 2.1<br />of OAuth 2.0; otherwise, it MUST use the https scheme" - This,<br />surprisingly enough, is relaxed in comparison<br />to<a href="http://tools.ietf.org/html/rfc6749#section-10.5">http://tools.ietf.org/html/rfc6749#section-10.5</a>.<br /><br />RFC 6749 states: "Authorization codes operate as plaintext bearer<br />credentials, used to verify that the resource owner who granted<br />authorization at the authorization server is the same resource owner<br />returning to the client to complete the process.  Therefore, if the<br />client relies on the authorization code for its own resource owner<br />authentication, the client redirection endpoint MUST require the use of<br />TLS."<br /><br />Why is Connect, in this particular case, less restrictive than OAuth?<br /><br /><br /><br />John, can you speak to why we’re allowing http redirect_uri values<br />when apparently OAu
 th
doesn’t?<br /><br />I had some questions on this point as well. I believe the thinking is<br />that since the client is protecting the secret and the code is sent to<br />the /token endpoint with client authentication, even if someone was able<br />to hijack the code value they couldn't exchange it for the access (and<br />possibly refresh) tokens. If we are trying to make things simpler, then<br />just moving all of it to TLS makes sense. To me, the only exception is<br />localhost. <br /><br />The attacker could inject the authorization code into the same<br />application as used by the victim in order to impersonate her/him.<br /><br /><br />For this to happen the attacker should also have gained control over the<br />RP (the application), i.e. have the RPs' authentication credentials.<br /><br /><br /><br /><br /><br /><br />Early OAuth 2 inherited the idea from OAuth 1 that the client didn't<br />need to have a TLS cert.  We were matching that.  At the IIW F2F we took<
 br />a
decision that we should match the RFC and require the client to have a<br />TLS endpoint if using a http redirect.(not a custom scheme)<br /><br /><br /><br />Earlier in this thread there is also a question about exact redirect_uri<br />matching and if it is required for confidential clients.   In the code<br />flow if the token is leaked through an open redirector then it can be<br />presented to the real client and the attacker gets in as the user.<br /><br /><br /><br />The OAuth AS side mitigation of this is the confidential client passing<br />the redirect URI to the AS in the token request and the AS performing an<br />exact match on the redirect URI, and failing if it is different.   In<br />the wild it appears AS are also not being sufficiently strict  on<br />matching that and causing some problems in deployments.<br /><br /><br /><br />The client side mitigation for this is using nonce in the signed token<br />to allow the client to check on its own if it initiated 
 the
request<br />through the same browser that presented the code. However that was left<br />as optional for code.<br /><br /><br /><br />At the end of the day the reality is that some of the large IdP only<br />allow exact matching of redirect_uri.   If some are strict and some<br />allow query parameters then clients using query parameters to carry<br />state will fail and not be interoperable.<br /><br /><br /><br />The WG decided that the strict matching of the redirect_uri by those IDP<br />is allowed by the RFC,  rather than forcing them to change and do<br />pattern matching for interoperability we precluded clients from hiding<br />state in the query parameters and forced them to use the "state"<br />parameter.<br /><br /><br /><br />So yes for a fully RFC compliant OAuth server with a client that is<br />truly confidential and not just pretending, it would be secure for the<br />AS to relax the matching for the redirect_uri in the request to the<br />authorization serve
 r as
long as it records that URI and is doing an<br />exact string match on it aginst the one sent to the token endpoint.   It<br />is not however safe for a client to assume all AS are going to act that<br />way.  The only safe thing for the client is to assume exact string<br />match.<br /><br /><br /><br />So while this relates to security issues the final decision was taken<br />for interoperability of the client.<br /><br /><br /><br />John B.<br /><hr /><br />Openid-specs-ab mailing list<br />Openid-specs-ab@lists.openid.net<br /><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br /></pre></blockquote></div></body></html>