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

David Waite <> Mon, 15 March 2021 02:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91F423A10DB for <>; Sun, 14 Mar 2021 19:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Status: No, score=-7.097 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1csnAVAwDqTS for <>; Sun, 14 Mar 2021 19:48:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 289E63A10DA for <>; Sun, 14 Mar 2021 19:48:13 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by (Postfix) with ESMTPA id AA9CE204741; Mon, 15 Mar 2021 02:48:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1615776492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u3384q5D05QSihLIK0ShA70maO463av7Wyp2RpJQQFw=; b=XjYctlhZMwBFZdGLr4+BuUERUmGnoPsW4Y55r+xKHzMu18mYmkuI530cIvId8CI7KimYPl iJJ8+4E2BoYN9sHcJWI7R5rBShhm8ZV5bcn17J19gBUch44fE495U+8/z/7GLtex/AuY7o qNvB/J00EajmA+Fzqn3qbZORSup63i4=
From: David Waite <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3AF4FB07-23F0-42B0-B08B-A091C57767A4"
Mime-Version: 1.0
Date: Sun, 14 Mar 2021 20:48:10 -0600
In-Reply-To: <>
Cc: Philippe De Ryck <>,
To: Tatsuya Karino <>
References: <> <> <>
Authentication-Results:; auth=pass
X-Spamd-Bar: /
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: Mon, 15 Mar 2021 02:48:15 -0000

> On Mar 14, 2021, at 8:36 PM, Tatsuya Karino <> wrote:
> On Safari, you have no workaround.
> 3rd-party cookie is dead, and all JS-writable data is removed in 7 days there.
> 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.
> I see... Thank you. I understood that it is difficult to re-creation Access Token silently. As reading your workarounds, I felt handling AccessToken inside SPA is a little difficult.

Refresh tokens wind up being a bit more valuable to bridge the state in the two sandboxes and let you get new access tokens.

The AS policy can also be adjusted potentially to give longer-lived access tokens when the type of access being granted has less security impact if leaked.

> Generally speaking, preparing Backend Server looks better from a security and UIUX point of view. If there is a Backend Server for the SPA, we can use the Backend as a Confidential Client, and create a session and save it on http only cookie for the SPA. If we have a human resource to do so... 

A back-end server only changes access token availability in the case where the AS security policy is that only confidential clients can be issued refresh tokens.

If you use a backend to expose/proxy API requests via a set cookie, remember that you need to protect against CSRF attacks. Some sites use the need for a manually-applied OAuth header as CSRF protection.