[Openid-specs-ab] Whether to allow http redirection URIs for confidential clients

Torsten Lodderstedt torsten at lodderstedt.net
Fri Oct 25 05:41:24 UTC 2013


What about 

http://tools.ietf.org/html/rfc6749#section-10.5

second paragraph, last sentence? 

We explicitly added this statement/requirement in order to address the specific risk associated with code theft when OAuth is used for authentication.



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


More information about the Openid-specs-ab mailing list