[OAUTH-WG] Implicit flow in the Security BCP draft -14

Aaron Parecki <aaron@parecki.com> Wed, 12 February 2020 23:43 UTC

Return-Path: <aaron@parecki.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4D6C112002F for <oauth@ietfa.amsl.com>; Wed, 12 Feb 2020 15:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id alT-ubE_Q03K for <oauth@ietfa.amsl.com>; Wed, 12 Feb 2020 15:43:43 -0800 (PST)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A49120019 for <oauth@ietf.org>; Wed, 12 Feb 2020 15:43:43 -0800 (PST)
Received: by mail-il1-x135.google.com with SMTP id i7so3348135ilr.7 for <oauth@ietf.org>; Wed, 12 Feb 2020 15:43:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8GdUtLGvdFQfUt/e8Ub4THBEAXhpoj7IbBMeH3A8bG0=; b=d7JoDA16zjJQw9mii+0iYGKI/TnLPWSA0/HjSNUevf5mO/gIxQ2VtggiHhwtdNlamy HATKJNCLmWl43beyiHnBWok2rPGDwiuRdO7RJcsjJEWkB39owVbzmCC7tnvA2zxX1OD9 9Yl7WV49vrA1Hf4w+hsOy6HYlJI/19XLGXU4O87JLcn0RcYZs0TIhUMtPeIkL772JoB5 RFz79TefFvhq0etqZPuZJ+GfLwjSs+BM9+8Tod9R3KkX9WrH/+ex3UwPdxhhfa9Vr9Sw LKUps6H9XjqfdxLqGs42h6pYBYXygRKJO/UEkiBIGr0qVhAQKvesrAdP59ThGjwBizLe ACXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8GdUtLGvdFQfUt/e8Ub4THBEAXhpoj7IbBMeH3A8bG0=; b=FMVAcrknoC1kBlD/LFOqCTCqLJPdeT+WfNXQ/QI/XD5tdr23tskmJQJLUrDKTjJrKc 6avazuG57tygiBJq7KNLfjHM2myrgs0HpZqU15nWSaIF9e9sZpeVzE+oakf5CayzsE0G Nw+hS2YOgt6EGlB1nir0u5ARIBC6+0BGV8ii9TzXzvkHbU11IEY8zaYkmqr1g19g5CCv Og6QuMCNQSHb3PVKgfXD0vqHtnEkiHccx8e6AH2KqSG+b1iGv4Mg3J/3FI48OHwqmTek ZwZUBDXQv1JPVaRALNh0sJ7Vj3G5QM5/BBcGifjW9JGvTqqHDdjRZZCr1wsXcHSO8dLE SoiA==
X-Gm-Message-State: APjAAAWolBSD9iy8xIOGaTpHQAcMtnHNu7v1rGv8KEuQ1Wl/Ai1eb3mT mvO3ZZZI3DzY7AMqltQA4NOwwfAJ1xE=
X-Google-Smtp-Source: APXvYqzlP/w/YieerKJhjG1Qt20qDqu4E19GSfKkTZ6FmolAiX90O/TGksInTfUqGZtNtLiMZcmNyQ==
X-Received: by 2002:a92:b506:: with SMTP id f6mr13847563ile.103.1581551022539; Wed, 12 Feb 2020 15:43:42 -0800 (PST)
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com. []) by smtp.gmail.com with ESMTPSA id v18sm184332ilm.85.2020. for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Feb 2020 15:43:41 -0800 (PST)
Received: by mail-io1-f50.google.com with SMTP id h8so4372253iob.2 for <oauth@ietf.org>; Wed, 12 Feb 2020 15:43:41 -0800 (PST)
X-Received: by 2002:a6b:3b10:: with SMTP id i16mr20888323ioa.46.1581551021540; Wed, 12 Feb 2020 15:43:41 -0800 (PST)
MIME-Version: 1.0
From: Aaron Parecki <aaron@parecki.com>
Date: Wed, 12 Feb 2020 15:43:30 -0800
X-Gmail-Original-Message-ID: <CAGBSGjoxMTvbTi1=_qcc+TPoSiGeV-PVLkcJrKqjQo6GE2+ZPw@mail.gmail.com>
Message-ID: <CAGBSGjoxMTvbTi1=_qcc+TPoSiGeV-PVLkcJrKqjQo6GE2+ZPw@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU>
Subject: [OAUTH-WG] Implicit flow in the Security BCP draft -14
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2020 23:43:45 -0000

Hi all, I'm reading through the latest draft of the Security BCP, and
noticed something I was hoping to get some clarification on. From the
latest draft -14 section 2.1.2:

>    In order to avoid these issues, clients SHOULD NOT use the implicit
>    grant (response type "token") or other response types issuing access
>    tokens in the authorization response, unless access token injection
>    in the authorization response is prevented and the aforementioned
>    token leakage vectors are mitigated.

My understanding is that there is no way to prevent access token
injection in the authorization response with just OAuth. It's only
once you introduce OpenID Connect that it becomes possible to prevent
ID token injection.

If my understanding is correct, then it seems like it would be more
appropriate for the security BCP to say something like "access tokens
MUST NOT be issued via the implicit grant." That would technically
still leave open the possibility of using the hybrid response types in
OIDC as long as the access token is delivered via the authorization
code exchange, but clarifies that there is no way to protect the
delivering access tokens via the implicit grant.

So my question for the list is am I forgetting about some way to
prevent this attack in OAuth? If not, can we rephrase this section of
the Security BCP to better clarify the intent here?

Aaron Parecki