Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application

Philippe De Ryck <> Sat, 13 March 2021 08:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 285D23A09E7 for <>; Sat, 13 Mar 2021 00:21:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=PCrmjESt; dkim=pass (2048-bit key) header.b=cfBrAFVf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OKKvvduZjvkE for <>; Sat, 13 Mar 2021 00:21:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3588C3A09E1 for <>; Sat, 13 Mar 2021 00:21:53 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id A74AF1E28; Sat, 13 Mar 2021 03:21:51 -0500 (EST)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Sat, 13 Mar 2021 03:21:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type :content-transfer-encoding:from:mime-version:subject:date :message-id:references:cc:in-reply-to:to; s=fm3; bh=laJVTtOTg28v 2iDXXmKJAtWnycTTVkKl37+DmagJtj0=; b=PCrmjESt7nI9BzXrBalwakoBg5f7 LDj/KT4pvfOUjwtevUQa9hyHEHdcEkgb47BacuNtiUgl6TesV5GsZS3tEilMnONe E7SXCfHV2ZTe2w8/tir5pXkuHM/Dlv7iOfc7ZeHAD+UW21pIwuGoMbaQ3Z0l34gO PHOrA/6q1KkdzhwYrj6XZ7ActTUBMFmoaqzYLbMYJ0/thWmupnVjSCtz9MuKeJ3I kGTvJhTeUgzPm5oY/AUGMJwu7W0IbsGcFJfo1/RPMXlN7sLrlr5E7dns/0hvisUP I4LJAOa9rUw9pvPT/5r8GNjloMDuP7C3sVCBzQJA6xm4jcoSYWcLySGPvA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=laJVTtOTg28v2iDXXmKJAtWnycTTVkKl37+DmagJt j0=; b=cfBrAFVfqx6dWp6T0NVsHjqoah29YOKn315rLFHC859wurZd+57x/AzNS YARLAZc4gNN9nIdji5vcv29fpbJe/XsgPc1bRGbDHBKzTE7qbT1vxzYzGqtyWC0x maGiBD0OH4IamSzIB+tUah8KePXnQaVCDaMdpboOB7srKOV1FfkE+NuvNrWF4exB ZTnANupJT9jE1HqZjbYfOIB9ZGJEpNY2HEzavc6bMoo9uBzWbi1JOLbNVccl9Bp1 yqJF+cK+rX2aKcrNzKQMEHXJ8IG5gvYr1z/R93YG2nNDsWw0bECjMdCKwBALZssE XF1uRjRYuCPEqHnXIFz1++wey7bZg==
X-ME-Sender: <xms:HnZMYGPZaTH4calZ5NX5y8YQaIrNDynSxrlg1wTuQ_OqIxw1s9ZgYA> <xme:HnZMYE-dmqzAcCbhMK0adnTSzvuCu8lta0SMIOxJS-KTyIjgKDOmyWy5uJ2gnT6Ob li1rXpNGN81aSn3jA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvfedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtgffhggfufffkfhgjvffosegrjehmrehhtdejnecuhfhrohhmpefrhhhi lhhiphhpvgcuffgvucfthigtkhcuoehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvg gsshgvtghurhhithihrdgtohhmqeenucggtffrrghtthgvrhhnpeetffevffekfeehgfeu jefhgeeftefgheffheekleeigeffieejudehuefgveehffenucfkphepkedurdduieegrd duvdelrdelheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtoh hm
X-ME-Proxy: <xmx:HnZMYNRMXuXnMohzzZhkhzOOtmmLFWXyhD-JLbrfl9qD345GcT2J8A> <xmx:HnZMYGuagFJr3bC8MfyTkMglcVnUjC9XAoCoausJ9Dn1zSED5q90oQ> <xmx:HnZMYOelZQw1uKnmk5pj_726cQjZK1-kxDVlCaIRT9rTyh0kL2-Xeg> <xmx:H3ZMYGmw0BHVQMBzxXgusaJWLjjx82d-YdTBKW7SmeOlbTmpvzPoBA>
Received: from [] ( []) by (Postfix) with ESMTPA id 904C51080054; Sat, 13 Mar 2021 03:21:50 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail-31ABBC5E-E4D9-433C-950B-AC2029754C72"
Content-Transfer-Encoding: 7bit
From: Philippe De Ryck <>
Mime-Version: 1.0 (1.0)
Date: Sat, 13 Mar 2021 09:21:48 +0100
Message-Id: <>
References: <>
Cc: Nov Matake <>,
In-Reply-To: <>
To: Tatsuya Karino <>
X-Mailer: iPad Mail (18D52)
Archived-At: <>
Subject: Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 13 Mar 2021 08:21:55 -0000

> On 13 Mar 2021, at 07:52, Tatsuya Karino <> wrote:
> By the way, I also wonder what is the better option to use OAuth2.0 on SPA Client (3rd party) with good UIUX.
> In my understanding, there are two options to achieve it.
> 1. Using response_momde=web_message or 2.Using Refresh Token with fixed maximum lifetime.
> But I have a concern on a practical use.
> For 1, Some browser could be restricted to send credential cookie to the authorization server from iframe.
> For 2, The Refresh Token must be saved on the browser, but it could be deleted on 7days in safari.
> Is there any workaround? or Is there any misunderstanding on my concerns?

As you stated, option 1 does not work in cross-site scenarios in Safari & Brave at the moment. Other browsers are likely to follow the same pattern in the future.

Option 2 only works if there are already tokens available, which is typically not the case at first load. Also, keeping long-lived refresh tokens in a browser is not always the best idea.

One workaround goes as follows:
1. When the SPA loads the first time, check if it has token material. If yes, done, if not, go to step 2.
2. Redirect the browser to the authorization server to run a new authorization code flow with PKCE, by setting prompt=none. This will prevent any user interaction and immediately returns either an authz code or an error.
3. The SPA loads again with the autz code/error. If it is a code, it exchanges it for tokens and all is good. If it is an error, the SPA simply shows the unauthenticated state (here, the user can start a new flow with interaction by clicking the login button)

Note that step 2 will include cookies, so it can resume an existing session between the browser and the authorization server. This cookie is always present since a top-level redirect is not a third-party scenario, so third-party cookie blocking does not apply.

Hope this helps