Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
"Brock Allen" <brockallen@gmail.com> Thu, 15 November 2018 14:01 UTC
Return-Path: <brockallen@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 5C564129385 for <oauth@ietfa.amsl.com>; Thu, 15 Nov 2018 06:01:35 -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 q9GhqVch-NiH for <oauth@ietfa.amsl.com>; Thu, 15 Nov 2018 06:01:32 -0800 (PST)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C0571128CFD for <oauth@ietf.org>; Thu, 15 Nov 2018 06:01:31 -0800 (PST)
Received: by mail-qk1-x72d.google.com with SMTP id q70so14341428qkh.6 for <oauth@ietf.org>; Thu, 15 Nov 2018 06:01:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc:in-reply-to :references:user-agent; bh=1Hs9kuE9LvrFXk0Ph6ngcV65SqDewFUpUHAHa4dqcHg=; b=H5hxFPAwOW/3MBgMBOo6Q2cVGDWublBZ/nLZO1VeoxKLrYZ13/qUphGuFddI+rwJIC F569AkS2JAYGbzcZhdTIdO85zPG9XkbJwygBLpFuBtMicWZthhpmePo2zCu8Vs/yNAjY GNq2VtKo7Nsz7LERPxyqkjijL7cf9nmMO1+N82UVyVPdPdgrEX3tscO651zWQP5FTKRF MoNkyGLI97/J75K6nn+KNtKB+uGozZLWjdemOHgFFMT/Wa8ZsVg3NZD10OYp1wmvC/4N tGLG67Pmhp7PJacfPxwyAOKvpjctv84ekEibtiVtG3lTknzmSFX/iXyJiKfy5mlRleGt KtKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :in-reply-to:references:user-agent; bh=1Hs9kuE9LvrFXk0Ph6ngcV65SqDewFUpUHAHa4dqcHg=; b=J7a+y8rOC7DLS+Oc/58ZTpyeuZIMG0M4PTOYVfRJKzw0Fr3zTH0EMnjE1kp0yBKBL+ nmot34fNBBdMGsYRHf5si1z3DSvRm8gVFBUEN3GXh0cBRY7VCG6916IMTgLtSTKX61a+ pC+ClhTmGRV6/2anjj9V/5zQnOfbZ6eYRVQwM6GmgX+SGnlv/T+dCNXv4f/60ulLW1fn 5xw1BmWGNYzWnnhf2VcbfM0JdWwBVddhjdQGDDF89e+a2a5gfEicofgeFKOX1dOR6ygo w2UOxp8MhLo/mMac2gJwi/8dwdtlI/ED3qvb2Jynz97m0x2IyClEJhNyLga/WuIeW7sC KkIg==
X-Gm-Message-State: AGRZ1gLDcbL+umaYhapx36xjK2p9NeZuA+3qK2WNxLjBvTdd5nn5nZJb D+/lCiEio2c5h8w9ERpp5sF5OxKC
X-Google-Smtp-Source: AJdET5fiYpzxCpknhoyS+enefxgpWJMy4CvuQ4m4OAB3gXxTIGpRggwPnQKS+DxDj46T6bLr3q6C6g==
X-Received: by 2002:ac8:44d3:: with SMTP id b19mr6211639qto.107.1542290490675; Thu, 15 Nov 2018 06:01:30 -0800 (PST)
Received: from [10.0.1.3] (pool-96-253-25-169.prvdri.fios.verizon.net. [96.253.25.169]) by smtp.gmail.com with ESMTPSA id q5sm17390756qtq.20.2018.11.15.06.01.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 06:01:30 -0800 (PST)
Content-Type: multipart/alternative; boundary="----=_NextPart_51060598.470372800206"
MIME-Version: 1.0
Date: Thu, 15 Nov 2018 09:01:27 -0500
Message-ID: <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com>
From: Brock Allen <brockallen@gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Aaron Parecki <aaron@parecki.com>, Hannes Tschofenig <hannes.tschofenig@arm.com>, oauth@ietf.org
In-Reply-To: <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net>
References: <VI1PR0801MB211299BED6B61582DC33B873FACB0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <CAGBSGjqHKVveZor-oKUWzsQ0Rg5Fk_d2dns_eQFqfvXJynyQaQ@mail.gmail.com> <9347fff8-f3b9-4ee9-84d3-5eebc8dd13f4@getmailbird.com> <309DAA7D-E9B9-4A89-B30E-5BE37DC6CC85@lodderstedt.net>
User-Agent: Mailbird/2.5.23.0
X-Mailbird-ID: 27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/U9qvGGqKsDrAG22vh3Ry23xm428>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
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: Thu, 15 Nov 2018 14:01:35 -0000
> Helps to prevent leakage, not injection in the authorization response. So then wording and its motivation could get updated to correctly reflect that. >> "OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client." >> >> Sure, but OIDC does provide a mitigation for this (even with implicit). > >This is about token replay detection at the RS. What mitigation does OIDC provide here? The wording doesn't go with that, then. My point about OIDC is that with the at_hash in the id_token provides a mitigation so the client can verify that the access token was issued to it. > The implicit grant was not equipped with the ability to issue refresh tokens simply because the working group didn’t want them to end up in the browser history, leak through open redirectors etc. This is different with code since tokens travel directly through a TLS protected connection. Well, if limiting the access token renewal to the user's session lifetime wasn't a conscious design goal, it's a very interesting side effect which does limit the potential of an attacker. > First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine. Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications. > It’s still possible to refresh your access tokens the way you mentioned above by sending another authorization request to the AS. This also could be added as a proposal for an alternative to renewing tokens. It provides more awareness to folks, and aids in a potential best practice depending on the requirements of the consuming app. > But let’s assume for a moment the AS, based on its risk assessment, decides to issue refresh tokens. Can you please explain how an attacker will get access to this tokens? Especially what the expected strength of the attacker would need to be? I don't have a profile of an attack. But I'm assuming it's no different than anything in the past we've been trying to defend against when we considered the potential for an access token to be exfiltrated. So my point is that an access token will expire so an attacker would then have to go back and re-attack the app to get a new access token to continue to have access to the user's resource. But now with refresh tokens in the picture, the attacker would have both and then not need to go back to the app to continue to have access to the user's resource. > I would also like to understand how a refresh token is any different from a long living cookie in the browser and what you think is the big difference to mobile apps when it comes to refresh token handling. To use the cookie, the app must be active, and the attacker must be attacking the app itself. Maybe a different way to say it is that an attacker must only compromise the app once to have long lived access, whereas without refresh tokens the attacker can attack the app once, but the once the comprised access token is expired they would have to re-attack the app to get another access token. Refresh tokens means they only have to get in once to the app, then they no longer have to go back to the source. Maybe there's a better way to convey what I'm trying to say... Also, I guess my question/comment about providing guidance for existing implicit flow clients is not up for discussion? Again, my reasoning is that it's a hard sell to always say there's exactly one right way to do something. And since so many clients have been built based on implicit flow that might not be able to change quickly to a new flow, perhaps there are "baby steps" that can be suggested to help them improve their security. -Brock
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Joseph Heenan
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Simon Moffatt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- [OAUTH-WG] draft-parecki-oauth-browser-based-apps… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Daniel Fett
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… n-sakimura
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Tomek Stojecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brock Allen
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Jim Manico
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… George Fletcher
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hannes Tschofenig
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Rob Otto
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Phil Hunt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Hans Zandbelt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… David Waite
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… John Bradley
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Torsten Lodderstedt
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Brian Campbell
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Vittorio Bertocci
- Re: [OAUTH-WG] draft-parecki-oauth-browser-based-… Aaron Parecki