IETF Logo Mail Archive

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 19 November 2018 15:37 UTC

Return-Path: <torsten@lodderstedt.net>
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 4EF23130DD3 for <oauth@ietfa.amsl.com>; Mon, 19 Nov 2018 07:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 34lQw0hDPOd7 for <oauth@ietfa.amsl.com>; Mon, 19 Nov 2018 07:37:03 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB6C130DC8 for <oauth@ietf.org>; Mon, 19 Nov 2018 07:37:03 -0800 (PST)
Received: from [80.187.80.89] (helo=[10.151.119.14]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1gOlbf-0007gr-Ad; Mon, 19 Nov 2018 16:37:00 +0100
Content-Type: multipart/signed; boundary="Apple-Mail-CB8EF993-E761-4728-947B-09D16A68B9B8"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <CA+iA6ugTpEAZe22=uwb31x+F2zVVdM9wUHrar1eiL6UO5e9xuw@mail.gmail.com>
Date: Mon, 19 Nov 2018 16:36:57 +0100
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <37CEB045-9A1A-43E0-88F5-50D3F5D705C3@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> <27627bee-aaab-44fd-9821-b58f7b33bc13@getmailbird.com> <7A852312-B129-4A0F-9914-8DC7E63FD12C@lodderstedt.net> <64a7f649-d2d8-4983-a564-5193adb4314a@getmailbird.com> <915498670.1574190.1542373190714@mail.yahoo.com> <A96E37F1-B09D-41C9-9F5F-DA7C133B00E2@lodderstedt.net> <57c8f36a-29dc-0365-af4f-96282e253702@connect2id.com> <CA+iA6ugTpEAZe22=uwb31x+F2zVVdM9wUHrar1eiL6UO5e9xuw@mail.gmail.com>
To: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CgJn2JikaJwcUAK97qC9M0QeRmM>
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: Mon, 19 Nov 2018 15:37:06 -0000

You mean the binding between refresh tokens and sessions?

> Am 19.11.2018 um 11:03 schrieb Hans Zandbelt <hans.zandbelt@zmartzone.eu>:
> 
> +1 to the suggestions that Vladimir raises; I've seen a fair number of requests  in the field for exactly that
> 
> Hans.
> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination with automatic revocation in case of detected replay attempts. 
>>> 
>>> How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attacker) submits one of the older, invalidated refresh token, the AS might interpret this as a signal indicating token leakage and revoke the valid refresh token as well. We used this technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 2012.
>> This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:
>> 
>> A valid refresh causing the session to be refreshed too
>> AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> hans.zandbelt@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.27.8 | Report a Bug | By Email | System Status