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

Vladimir Dzhuvinov / NimbusDS vladimir at nimbusds.com
Thu Oct 24 19:56:24 UTC 2013


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.


More information about the Openid-specs-ab mailing list