Re: [OAUTH-WG] Recommendations for browser-based apps
Nov Matake <matake@gmail.com> Wed, 20 September 2017 02:11 UTC
Return-Path: <matake@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 2BFAE126DD9 for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 19:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 Kvy4N4b8vIdj for <oauth@ietfa.amsl.com>; Tue, 19 Sep 2017 19:11:33 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 0B351124B18 for <oauth@ietf.org>; Tue, 19 Sep 2017 19:11:32 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id d8so875373pgt.4 for <oauth@ietf.org>; Tue, 19 Sep 2017 19:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lVuvYW22uVq88wpaX6UA8vyBx6VKzHhZMIkzU3OGOZQ=; b=ou07PxyDok8gw1+0cabI0Qe2R0W5Rll7XwG/VZo8eWE2OC/GCKVyIemvPU7jhjH1jI C4C6PhTNR+ap4GX25F8uv+JIWVB/4qNNbgrsPBm9wtfR4YnR4g7SSDfTJGn8ljz1oeua UsyHQj/RUCTq3Nz9dLNf57mS0YwMcQ/ciBerYXQoh/6ZBimzmHQt0nhdn+4DyKsGbEWH LZiMHVTSQGvnotVlo0h8mnMxCjDJEWqwLYztbbR8cjBVAyydnFYdkm2U8JTSIrVeBnk7 6RLTS5v79GD61BhrO8aqzmoCzWVbbV80A8iesRha7IrAXdNEHNlGbEWR6Zd2RnOSJtq+ GM6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lVuvYW22uVq88wpaX6UA8vyBx6VKzHhZMIkzU3OGOZQ=; b=iUn1AWAEGTLq96wG7z7WWl/dRlVWhvmFa3L6adHg/SHagdf6h+TxI6ubsbpHcJ8GCr tr0YIwGinyfl5jdIIq/aa5b2HU/6vW99RvhmfTPKmCh5J/rpon+0s3gB2P2Ra5yf7I+x ASmOwX3IgwBao/DSsFTWZP/oC+PO/0jRuSau6ELbg+8hsTVRVBywdXwwq5cxcJhCErtH 8/JkhUaQAVj03tOafHxruGW9Y9J0gV+aUq5euRJGkJyyNmFN2hlcOuz6ajqgOsK7dlii PtN9wJQbIrWWhcGpmrh0/J7y58zINSbo4gu+wdAeMKkeMs48ILA7MWSGMKv/x2LFB0hO Nn8A==
X-Gm-Message-State: AHPjjUgoWzAhrupzbCrzqC4uL5yrPbyfeSBVisNa/pCA20NpDoGmd2iB O5PPAv//VYVAk0iQwsiO07JyCdZM
X-Google-Smtp-Source: AOwi7QCnNcBEo9fIlH23FYTsilNnwYn2JuTp7KSlQQznnNnhy+O9+gSycWEpx6Yj8PRTAVvRb6Gm7g==
X-Received: by 10.98.207.134 with SMTP id b128mr593465pfg.202.1505873492204; Tue, 19 Sep 2017 19:11:32 -0700 (PDT)
Received: from [100.88.219.90] (1.69.239.49.rev.vmobile.jp. [49.239.69.1]) by smtp.gmail.com with ESMTPSA id o17sm5124643pfa.22.2017.09.19.19.11.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 19:11:31 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Nov Matake <matake@gmail.com>
X-Mailer: iPhone Mail (15A372)
In-Reply-To: <CABRXCmwDQ_uZXDaaX6gxn_J_FnaCDucA-5uZwF6K1uHMQs6nzw@mail.gmail.com>
Date: Wed, 20 Sep 2017 11:11:29 +0900
Cc: John Bradley <ve7jtb@ve7jtb.com>, OAuth WG <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <22DCF344-9723-453C-B997-9475521C3777@gmail.com>
References: <CAKAMr-Dws2RVRLv+xTa7j2zk+yhpCpYN-jUgxFos+j--Abv4uQ@mail.gmail.com> <CABRXCmwKDOSQQrDdCVBkDWSi85A7FL_R9d9sNzgdBTE_HyKDMw@mail.gmail.com> <14E11D6D-3CA4-4945-93B5-96F40D17463E@oracle.com> <CAOahYUwYT-mFrdN-FvZArNCmVMn8G6X8504Z9EFY_rZ7A328qA@mail.gmail.com> <7630385B-8366-4B11-A5CA-BEE18F96AB8B@ve7jtb.com> <5C40C2B2-A673-4940-8376-55D448271A4C@gmail.com> <CABRXCmwDQ_uZXDaaX6gxn_J_FnaCDucA-5uZwF6K1uHMQs6nzw@mail.gmail.com>
To: Bill Burke <bburke@redhat.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/keKsJ636mT4WhNTMnaCzG4Cu1XI>
Subject: Re: [OAUTH-WG] Recommendations for browser-based apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 20 Sep 2017 02:11:35 -0000
you have redirect uri restriction there. nov > On Sep 20, 2017, at 9:44, Bill Burke <bburke@redhat.com> wrote: > > Cookies are vulnerable to CXRF. > >> On Tue, Sep 19, 2017 at 7:48 PM, nov matake <matake@gmail.com> wrote: >> Why not using http-only cookies instead of refresh tokens? >> If the app can interact with AuthZ server through a hidden iframe with >> prompt=none param, you shouldn’t need refresh tokens. >> >> If your SAP is running on a different domain with the backend server, >> Safari’s Intelligent Tracking Prevention will break the hidden iframe way >> though. >> >> On Sep 20, 2017, at 7:32, John Bradley <ve7jtb@ve7jtb.com> wrote: >> >> Right, Refresh token is bearer for native apps, that is why we came up with >> PKCE to protect code. >> >> For Angular the code flow with PKCE is probably better than the token >> response type. >> >> However with bearer tokens it is still riskier than code with a confidential >> client so the AS should take that into account and not allow refresh tokens >> to live forever. >> >> One future way to protect refresh tokens and perhaps Access tokens is to use >> token binding to bind the tokens to the user agent. You could do that now >> for refresh tokens in Edge (Chrome has TB off by default still). >> >> I think more work needs to be done to come up with a best practice for SPA. >> >> John B. >> >> On Sep 19, 2017, at 7:02 PM, Adam Lewis <adam.lewis@motorolasolutions.com> >> wrote: >> >> Only for confidential clients. No authentication is required for public >> clients. >> >> On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> >> wrote: >>> >>> Except a refresh token is not purely bearer. The client is required to >>> authenticate to use it. >>> >>> Phil >>> >>>> On Sep 19, 2017, at 2:33 PM, Bill Burke <bburke@redhat.com> wrote: >>>> >>>> I'd be curious to the response to this too. >>>> >>>> Seems to me that refresh token has the same possible security risks in >>>> an Angular app as an access token, except the refresh token is valid >>>> longer....Still, if you did the implicit flow, you'd have to have >>>> longer access token timeouts as it would be really annoying for the >>>> user to have to login again and again in a long session with your >>>> Angular app. >>>> >>>> We have a javascript adapter that does Authz Code Flow with PKCE for >>>> our Angular app. It also does CORS checks on the code to token XHR >>>> request just in case on the IDP side. >>>> >>>>> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <sbueringer@gmail.com> >>>>> wrote: >>>>> Hi, >>>>> >>>>> there were some discussions in January regarding recommendations for >>>>> browser-based apps >>>>> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). >>>>> >>>>> I'd just like to ask if the Authorization Code Flow with PKCE is a >>>>> valid >>>>> option for Single-Page-Applications (in our case Angular), because >>>>> Implicit >>>>> Flow cannot be used in our scenario. >>>>> >>>>> Authorization Code Flow with PKCE eliminates the necessity for client >>>>> secrets, but our concern is that exposing the refresh token to the SPA >>>>> might >>>>> be a security risk, compared to the Implicit Flow were no refresh token >>>>> is >>>>> exposed. >>>>> >>>>> What's your take on this? >>>>> >>>>> Kind regards, >>>>> Stefan Büringer >>>>> >>>>> P.S. I couldn't find that much on the internet regarding Authorization >>>>> Code >>>>> Flow with PKCE in SPAs, if you have some recommendations for good blog >>>>> posts >>>>> I would be grateful. >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Bill Burke > Red Hat
- [OAUTH-WG] Recommendations for browser-based apps Stefan Büringer
- Re: [OAUTH-WG] Recommendations for browser-based … Bill Burke
- Re: [OAUTH-WG] Recommendations for browser-based … Phil Hunt (IDM)
- Re: [OAUTH-WG] Recommendations for browser-based … Jim Manico
- Re: [OAUTH-WG] Recommendations for browser-based … Adam Lewis
- Re: [OAUTH-WG] Recommendations for browser-based … John Bradley
- Re: [OAUTH-WG] Recommendations for browser-based … nov matake
- Re: [OAUTH-WG] Recommendations for browser-based … Bill Burke
- Re: [OAUTH-WG] Recommendations for browser-based … Jim Manico
- Re: [OAUTH-WG] Recommendations for browser-based … Nov Matake
- Re: [OAUTH-WG] Recommendations for browser-based … Josh Mandel
- Re: [OAUTH-WG] Recommendations for browser-based … Neil Madden
- Re: [OAUTH-WG] Recommendations for browser-based … Jim Manico
- Re: [OAUTH-WG] Recommendations for browser-based … Jim Manico
- Re: [OAUTH-WG] Recommendations for browser-based … Bill Burke