[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