Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

Travis Spencer <> Tue, 20 March 2018 11:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38A7012702E for <>; Tue, 20 Mar 2018 04:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 81clkxj49gBU for <>; Tue, 20 Mar 2018 04:48:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FC47126DED for <>; Tue, 20 Mar 2018 04:48:45 -0700 (PDT)
Received: by with SMTP id v23-v6so1341120oth.9 for <>; Tue, 20 Mar 2018 04:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DQxB1yNeHcrdL3RdpCaEydYQlWNaqElO8o9vPJ3KBHo=; b=1sMtvARuyuIXN++rIBkdzjb/04mi4SuBH7xK1ChdlSZ4vAXoeFxxvILrWWR/WuAd5Q pzeiVQtUFAyfh6m//xivOkjHNG10NMK2pDNDA+oeASg0k9b0floXh+YC5TI61+6TpCSB Fta7Zm3AoIFU0A87kH13iw0slhvNI8wIECFAv8GyutuO/f8cmijw049pWvT8xOXBlmJC KcbIQ6Z5xmlrQxI/oZrX2xSgR7QF6VHL6NIHeOb2d8J/Bd+Ie+hi9wPMd9zbvf+1OhVU BKxWehvyyWjE3ES3d0z/o+gtC3A5CXN7VPdkJMi0UaOks6Ib7TvW76W7zDdOKY3V+Nzz GRHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DQxB1yNeHcrdL3RdpCaEydYQlWNaqElO8o9vPJ3KBHo=; b=SIPvKe2Iyu2cSe9sxX0C7VX6tad0zTQaeIDedM8MHatyvuhtXKkSRSz3HvZx4MdXpj tcz058ANQriRbapQpwkNHqoaUt2MX69cRZk0byVX3DfTGn27HcGmas+F0odPV78E4h2j yyV5qk4CdimRugNQ9lpzAQK1hdrnBpL2N0GYarPv4fejVohgqF3k6YqS4WpFGIVE4yc/ o2y+egpG4gxF0z7CRCWFeD1WOA2Yc7JpNL4n6V7frtqKSV6luWqLD1g7LpWf7vL+egKz nT4bDKs4mJPAXJ2YKJBGQT0M6dSYSs8BQCiqf4srkynkcleeNVruFdR0k2VbGoQgdA6G 2p8w==
X-Gm-Message-State: AElRT7EEmUgsxXAqSm1DuUarjLqS4MepVlPywi25FYrNpKPmy0pGzHty //mgK1olHSIYG1LZwG2+w55wc5oEqLn3y3QBaZ/bvlOl
X-Google-Smtp-Source: AG47ELtjNyCUO+URAwMH2jFkiz0S3jEBM3AO7RHEhGVvnKxEM7GjQnJEI8GasqYVQx8D16DLM6VaET14oNlOn7CY3z8=
X-Received: by 2002:a9d:4992:: with SMTP id g18-v6mr9695405otf.238.1521546524589; Tue, 20 Mar 2018 04:48:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Mar 2018 04:48:24 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Travis Spencer <>
Date: Tue, 20 Mar 2018 12:48:24 +0100
Message-ID: <>
To: Joseph Heenan <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Mar 2018 11:48:52 -0000

I read through this doc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
    - No mention of frame breaking scripts for non-CSP aware user agents
    -  No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
* The examples only use 302 and don't mention that 303 is safer[1]
   - Despite what it says in section 1.7 of RFC 6749, many people
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to in the example. This is a real domain.
Suggest instead. Same issue in 3.1.2 where is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuff
including other specs! I don't think that's warranted, and I am not
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.


On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <> wrote:
> Hi Torsten,
> As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> Redirector" could I think be made more explicit.
> Currently it explicitly mentions the invalid_request and invalid_scope
> errors must not redirect back to the client's registered redirect uri.
> defines several more
> potential errors that appear to fall into the same category. I understand to
> block the attack fully we need 'must not redirect's for all the kinds of
> error that could cause an automatic redirect back to the client's registered
> redirect uri without any user interaction - 'unauthorized_client' and
> 'unsupported_response_type' seem to fall into that category. 'server_error'
> also seems dodgy (I would wager that on some servers that are known ways to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
> Thanks
> Joseph
> _______________________________________________
> OAuth mailing list