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

Torsten Lodderstedt torsten at lodderstedt.net
Mon Oct 28 06:41:06 UTC 2013


I agree.

I just wanted to point out the different protection goals of TLS and the ID token.



John Bradley <ve7jtb at ve7jtb.com> schrieb:
>That's true.  However if an attacker can firesheep the user nothing is
>safe.
>
>While I personally think giving every RP a free cert is the best
>solution to this issue, that probably won't happen (though startssl
>certs are free, I don't know what would happen if everyone asked for
>one.)  The financial argument is weak, it is mostly a lazy RP argument
>and verry small hosted guys who cant run TLS on some free services.
>
>Allowing http: to be an exception AS can make is not totally
>unreasonable,  however Caution needs to be taken by the IdP not to be
>too loose about it.  Offer a free cert first.
>
>If they won't do TLS connect using the code flow and a confidential
>client is still better than a password.
>
>John B.
>
>
>
> 
>
>On Oct 27, 2013, at 1:29 PM, Torsten Lodderstedt
><torsten at lodderstedt.net> wrote:
>
>> 
>> Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> schrieb:
>>> Here is the sentence you refer to:
>>> 
>>> "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."
>>> 
>>> That note was meant for general OAuth 2.0. With OIDC we have the
>signed
>>> ID token, so clients will be using that instead to authenticate the
>>> resource owner.
>> 
>> The ID token won't prevent an attacker to steal a code on the wire
>and use it to login with the victim's identity at the legitimate
>website (client). The Id token prevents a rough client from
>impersonating a user.
>> 
>>> 
>>> I read the entire section carefully, and it's fully in line with
>>> section
>>> 3.1.2.1 that I quoted in my previous email, as well as with what
>>> Connect
>>> has now specified. I.e. there is a strong recommendation to use TLS,
>>> but
>>> there's also the understanding that TLS wouldn't be practical for a
>>> number of clients and that's taken into account too.
>>> 
>>> 
>>> Vladimir
>>> 
>>> 
>>> On Fri, 2013-10-25 at 07:41 +0200, Torsten Lodderstedt wrote:
>>>> 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/20131028/b8aaf081/attachment-0001.html>


More information about the Openid-specs-ab mailing list