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

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Fri Oct 25 12:29:56 UTC 2013


> Why should connect support deployments with a bad security setup? I
> don't want our codes to leak and to be abused by attackers.
> 
There's a huge number of websites on a tight budget that don't have SSL
certs. If we force TLS on all clients they won't be able to use OpenID
Connect at all. This will be a loss for what the protocol aims to
achieve.

We can provide a sensible path for websites without SSL certs as well as
for security minded people / providers. For that an OP may reject
registration of clients without a HTTPS redirection URL, or the OP may
warn users that they're about to login to such a site, so the user can
then deny login or release only minimal claims. 

If we want OpenID Connect to appeal to a wider audience and be useful
beyond the corporate world this is a sensible thing to do.


> Furthermore: I don't get the intention of " confidential client needs
> to be required to use http". Does it mean confidential clients are
> forced to use http?
> 
I was also wondering, perhaps something else was meant?

> Regards,
> Torsten.
> 
> 
> 
> John Bradley <ve7jtb at ve7jtb.com> schrieb:
>         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 authenticatio n, 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 exac t
>         > 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
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab




More information about the Openid-specs-ab mailing list