IETF Logo Mail Archive

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Nat Sakimura <sakimura@gmail.com> Tue, 27 November 2018 15:58 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94214130E72 for <oauth@ietfa.amsl.com>; Tue, 27 Nov 2018 07:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh6LHXA_uRm1 for <oauth@ietfa.amsl.com>; Tue, 27 Nov 2018 07:58:11 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 45501130E67 for <oauth@ietf.org>; Tue, 27 Nov 2018 07:58:11 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id k198so22848143wmd.3 for <oauth@ietf.org>; Tue, 27 Nov 2018 07:58:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D8PrpXM0D4a4+cdEEXyOGdWbn3peI8jOHqyL6P1n51I=; b=RmZjZL7uCr1M5oedDnij7Ox0yhRFbefk8hI5NaAEP4E7zKKvaUOmwaK++/CzbylwWD 6QsXhFTfYEiIrGLyXcMEwkx3XG/gZ95ajLccIcqj2hMGGJ0xES6WqKgYpu9l4VGG/nI1 N7ekLfSt9uyhFl+R+eUwloZvC1umcS1SJXmcrMY7DWFS/CQf0tJpgA8WaDQ4++n7Qhwv tnIMDdRBzTLqrhNxiXbESIdR6+BwGDFfCB43KhI4fKZX8ERIByEDIbkPgXF6YErzSlcK eCaNmb/FcG5ZTCwYaXN3YqZZ+quIRTD1Q8+D+cWGdD/evY1/HaQz4xnfhawlkVCPqHXG RgDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D8PrpXM0D4a4+cdEEXyOGdWbn3peI8jOHqyL6P1n51I=; b=o+UKEwdGmI6p/LJQ5pT6+UyaOYzQClA+KaB3neQ9UjDVwZUp57Cb8KuoeaDlieqBP6 c/s7xuhkCrvDruDsXn+TrKfTwL9zPX/Z+H9n8MN4D7VcYCsHaVlUgrcjXoDYLm/nFOIF YbbreeAcQnkqGUctKSpyxzGCMgKROLxBQ4AV9sUuiYwTLQLW9Xt6HJfzR7wIxzGJlYN5 am/0vPKhlqPQPjQLHC6JV1ruuCIp6ogzs/V+EP+4A7bhN1gC1BIitO0/JnLEChP7jSpq yRNL4oHAJ9DYLVpfEt3Bc2v72VlyddhdKB8obaMuf+rF9DlfQQRlA4IPcjCgETfN2dB0 c2lg==
X-Gm-Message-State: AA+aEWZxyQCznLDUdsABwppXJs96YQBX9VFFXxAjv5XRt1BeD0i9sbyw bapMPYJKukLsNkkxkTo+WuRtCg3LVOD0jTZfK2kbppgt
X-Google-Smtp-Source: AFSGD/WgJg3wrxB6+1ykfvCLh8eXB4zM9Aok4bWh0MinKEGMYmcbdaFBnPWOqEXI7UBKw2LDGH679WhwA//jkfOaIEg=
X-Received: by 2002:a1c:9855:: with SMTP id a82mr5379011wme.20.1543334289439; Tue, 27 Nov 2018 07:58:09 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0801MB211266BA6F6E06FFB3081425FAD80@VI1PR0801MB2112.eurprd08.prod.outlook.com> <5494f764-2d14-089a-8fe8-132a65e32d5e@manicode.com> <8935ff0f-aeab-c773-5e2d-6fedcc29119d@connect2id.com> <CABzCy2D0JAr-C1-jTcodpBdoUNx1We3JDg-PMcsOBL1Ga_m-Hw@mail.gmail.com> <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>
In-Reply-To: <2297d085-28f2-15dd-6dba-937dce9f2122@manicode.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Tue, 27 Nov 2018 16:57:57 +0100
Message-ID: <CABzCy2AW0dvmEqfHgd=-ULdYSxnUXwrz6jiCBpKw7MQSu-YFbA@mail.gmail.com>
To: Jim Manico <jim@manicode.com>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth@ietf.org, "openid-specs-ab@lists.openid.net Ab" <openid-specs-ab@lists.openid.net>
Content-Type: multipart/alternative; boundary="000000000000178328057ba784e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/J_4bt45Su350smsfSf--9Xsv8ww>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
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: Tue, 27 Nov 2018 15:58:21 -0000

I am not talking about SPA.
The client is a regular confidential client that is running on a server.

Best,

Nat Sakimura


2018年11月27日(火) 16:55 Jim Manico <jim@manicode.com>:

> Nat,
>
> How is proof of possession established in a modern web browser in the
> implicit flow?
>
> My understanding is that token binding was removed from Chrome recently
> effectively killing browser-based PoP tokens.
>
> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/
>
> Am I missing something?
>
> Aloha, Jim
>
>
> On 11/27/18 9:00 PM, Nat Sakimura wrote:
>
> I am actually -1.
>
> +1 for public client and the tokens that are not sender/key constrained.
>
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming.
>
> Implicit (well, Hybrid “token id_token” really) is very useful in certain
> cases.
> Specifically, when the client is confidential (based on public key pair),
> and uses sender constrained (key-constrained) token such as the one
> explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
> very useful.
> (Key-constrained token is the remaining portion of this draft that did not
> get incorporated in the MTLS draft. )
> In fact it is the only viable method for Self-Issued OpenID Provider.
>
> So, the text is generally good but it needs to be constrained like “Unless
> the client is confidential and the access token issued is key constrained,
> ... “
>
> Best,
>
> Nat Sakimura
>
>
> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <vladimir@connect2id.com>:
>
>> +1 to recommend the deprecation of implicit.
>>
>> I don't see a compelling reason to keep implicit when there is an
>> established alternative that is more secure.
>>
>> Our duty as WG is to give developers the best and most sensible practice.
>>
>> CORS adoption is currently at 94% according to
>> https://caniuse.com/#feat=cors
>>
>> Vladimir
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> --
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

v2.23.0 | Report a Bug | By Email